架构师训练营-第十周练习：作业

[rooobot]

问题：

关于微服务架构（中台架构、领域驱动设计、组件设计原则），你有什么样的思考和认识？

答：

既然问题是问我对微服务架构有什么样的思考和认识，那我就不再描述微服务架构本身的细节了，纯粹的谈一谈我对微服务架构的理解。

软件工程界没有银弹是大家已经达成的共识，同样，架构设计也没有银弹，现在每个公司或团队都说自己采用的是微服务架构，似乎微服务架构已经滥大街了。这些年来，我个人有个感受就是，浮躁的技术人很喜欢去追那些新鲜的技术名词，然后稍加解释都变成了精通XXX了。

我始终偏向于一种认知方式：一门技术，或是一种架构模式，都是为了解决某些问题的。微服务架构也不例外。

老师在视频课里讲到当年淘宝团队没有使用微服务架构之前，线上发版的时候，一堆的人在公司熬夜打游戏的时候，我感受到了深深的共鸣。几年前在某大公司就职的时候，也是一样，公司的核心业务系统采用CVS做版本管理，核心业务系统的源代码全部在一台unix机器上，大家平时开发就是通过远程登录到自己的个人账号目录下进行远端开发，或是通过一些FTP工具连接远端在本地开发后再上传到无端的目录。本来分支的管理就不太规范，加上几十人的团队，有的模块几个人在同时开发维护，每次一到发版的时候，所有的人就害怕，我当年就经历过老师说的那个“只修改了一行代码，肯定没有问题，但同样的陪着团队熬夜到发版成功”场景，是亲身经历。也就是经历过那一次之后，我找我的直接主管谈了我对系统的看法。

但是没办法，一个人是无法去推动技术架构的变更的，更何况是整个公司的核心业务系统。当时，公司的收付费业务有很多的问题，比如重复扣费，重复付费等等这些我们觉得不可思议的事情，基本上每天都在发生。于是，我便承担起了对公司整个收付费业务重构的需求。

当时，也是考虑到系统的现状，我提出了两套方案：一种是轻量级的基于Hessian RPC的方案，另一种是重量级的基于EJB3的方案。最终，领导决定采用重量级的EJB3的方案来实现。

于是，我便将系统做了模块的拆分，整个系统需要对接到多个不同的业务系统做收付的业务，同时，要支持财务在处理收付业务时，对任何一个业务系统的数据都是自由选择不同的渠道厂商来处理，当时对接的厂商有三家，两家支持所有类型的收付业务，另一家只提供实时缴费的业务。这里面还要符合财务流程的合规，需要有权限的分级管理，同时，还有其它的一些审计功能，资金安全等等。

在平台的设计阶段，我首先将收付的业务进行了统一的抽象，只关注于纯粹的业务流程，设计好业务流程的抽象之后，再考虑如何组织不同业务系统的数据，如何自由的选择不同的厂商进行业务的处理等等。然后再将不同的业务功能进行剥离，形成不同的EJB服务，对于请求量大的EJB服务，通过前置一个负载均衡来部署多台相同的服务来缓存请求的性能问题，当然了，这还涉及到DB及其他的设计。

为什么说这些呢，其实现在回顾一下，当时的这些设计基本上就是一种微服务的雏形了，不同有EJB实现不同的服务，通过weblogic或是jboss来实现服务的治理（只是服务治理的能力比较弱）。

现在说起EJB，没有人会觉得那个东西好，也没有人现在还会愿意去用那些东西，但是，在当时，它确实是很好的解决了我们的问题，合适的才是最好的，不是吗？

微服务架构也一样，技术始终是为业务服务的，我们不需要什么高大上的东西，我们需要能解决我们问题的东西。

后来Spring Cloud刚出来的时候，所有内部调用都是基于HTTP的协议来处理，请求的量级随便一上去，整个吞吐量马上就会下来，那个时候会用这一套来做吗？反正我是肯定不会的，当时，我还是采用了Spring Boot + Dubbo的方式来做了。当然了，现在Spring Cloud发展得越来越好了，尤其是Spring Cloud Alibaba，直接整合了Dubbo等等很多优秀的组件。

严格意义上来说，一整套微服务架构会包括很多的组件，比如：RPC框架、注册中心、配置中心，统一网关、分布式链路追踪、服务治理平台、统一日志中心、监控和告警中心、业务模块等等。

但不是每个说自己都采用微服务架构的团队都实现了这一整套的方案。也不是说就必须要完整的实现这一整套的方案，这一整套的方案提供的一种解决问题的思路，当你充分理解了这里面的这些思想，不完整的实现这一套，也能通过其它的方式来达到同样的目的，也许这就是所谓的平衡与裁剪吧。

所以，只有合适的才是最好的。

写到这里再回看，似乎没有从微服务架构本身去谈我对微服务架构的理解和认识，我也是确实有感于老师说的那个例子，想起了当看一几乎完全一样的经历，所以从另一个角度谈谈我个人的理解和认识吧，这次的回答算是有点偏题了。