我公司的技术架构演化（五）微服务的演化

2019年开始，业务开始了突飞猛进的发展，我们的日活基本在30~100万之间，需求越来越多、越来越复杂，尤其是面向UI交互的变化是非常频繁的，光详情页就有9个版本之多。

面对这类问题，技术童鞋应接不暇，各种特判满天分，微服务直接面向上游的UI交互的时候，明显对业务的理解是很吃力的；

例如：我们在评估的详情页改造的时候，在详情页加一些用户的信息、加一些商户的信息，前端虽然知道要哪些信息，但不知道去找谁要接口，于是，每次评审只能拉上一大堆后端，通过PRD一起讨论，谁提供哪些信息。而实际推进工程中，后端的思路就是，我只是信息提供方；所以，大伙的配合度很低，并且后端也没有动力去了解需求背景，导致需求经常因为很机械的协调，出现“生硬”的交互。

image.png

于是，我们提出了一个概念：“大前端”。

大前端的普遍理解是，大前端是前端和客户端的集合体，而我认为的大前端则是：“面向交互编程”的团队，而大前端团队一样会有后端，这些后端则是要面向交互编程的。

image.png

我们成立了一个大前端的虚线组，将后端的一部分业务sense比较好的人放进来，让他们来参与面向交互的开发；这样的话，后端的资源协调一律可以以大前端的后端团队来做，解放了前端很多的精力。

但我们还面临着另一个问题，就是面向各类业务的特判，还是会放在微服务中，这导致微服务既要处理面向交互的特判，也要处理业务流程。这个问题是刚才的分工无法解决的；面对越来越多的特判逻辑，代码的难度、易读性、测试的工作量成指数上涨；于是，我们就开始了建设中台，把各个服务之间的通用逻辑下沉，个性化的逻辑上浮的各个业务端。

image.png

我们进一步将后端进行垂直拆分，把做中台的和做业务的分开，中台负责向业务赋能，提供通用核心能力；各个业务线基于中台的能力，开发自己的特判逻辑，并向上提供组件。

后端的架构来一张整体的全景图（缺少UI面向交互编程的后端逻辑，这块我伴随着模块化的思路去讲解）：

image.png