为啥我用了微服务架构，软件还是不好修改啊？

很多人跟我说：老师，我也用了微服务中间件啊，为啥我的程序还这么复杂，这么不好阅读理解、不好修改、不好组合啊？

嗯嗯，问题其实很简单，只有约束规定，没有约束手段。所以我比较喜欢Golang或Ruby on Rails这样的工程语言，特别适合中国这些万金油、需要大规模堆人来作业的开发模式。

那应该怎么办呢？

我告诉大家一个方法，只有这样方法一起用，你的微服务才能真正成为微服务。 总的思路其实就一条：要故意强制约束到小。

一、UI层

你一定要基于类似 小程序的技术 ，而且一定要做在智能手机里。只有这样，你才会受约束。因为智能手机屏幕小，输出就少，因为智能手机没有键盘和鼠标，所以你输入也只能少。

咱们中国万金油程序员，不会开发程序，往往是界面上的功能多复杂，代码就多复杂。所以啊，让UI界面上通过强制约束倒逼它不能放太多功能，代码就就少多了。这是前提基础条件。

而且，最好是把类似小程序的技术，内嵌 在类似IM（微信）这样的移动化协同门户里 。过去咱们做功能模块，都有个集成门户，左边是层层叠叠的功能树，右边是各种指标图，复杂得就像驾驶飞机。现在好了，被内嵌进一个类似即时通信这样的软件平台里了，没有菜单树了。那怎么办啊？嘿嘿嘿，小程序写的功能，只能通过场景来触发弹出出现了。哪里还有有形的ERP体系，哈哈哈，都被场景打碎了。

不是功能复杂就是好产品。

二、逻辑层

UI层有：移动协同门户+小程序UI组件，那逻辑层也需要三个东西：Serverless + 分布式微服务中间件 +Docker 容器。

FaaS我是特别赞同的。很多人不会写函数，都没有经过函数设计编写的训练，如函数命名、隐藏性、函数输入输出参数设计、函数异常保护、函数日志、函数返回值，这都是需要精心设计的，需要天长日久训练的。我曾经见过1000多行的存储过程，谁都不敢动，很少有人能全看明白。

所以， 通过Serverless这种函数编程，就把一个功能强制约束要做简单。

很多人问过我一个微服务到底要拆到多少粒度合适？我说，拆到你能掌控了的粒度就行了。拆的细了，是灵活了，但要修改的时候，可能需要十来个函数才能做到你想要的效果，忘修改一处，跑出来的结果就不是你预想的。这就很影响效率和质量，进而影响了成本。如果你把所有逻辑都一股脑放在一个函数里，还是太复杂，就和那个1000行的存储过程一样。所以，该拆多细的粒度，根据你这个万金油的能力来。要知道，大部分的 程序员 都是呈现正态分布的，天才和蠢货都挺少，大部分人都是中庸打酱油人，所以你觉得拆的差不多了，你能掌控的住，那说明大部分人都能掌控住。这种粒度就够了。

一定要有Docker。

Docker就意味着物理隔离（虽然也只是假物理隔离）。咱们过去写万金油软件，哪里需要对接，就调用一下。这样天长日久就形成了很多文档上没有记录的系统关联调用。如果用了Docker，嘿嘿嘿，都隔离了，你咋调去。就得强制让你不能调用，才被迫想到通过统一的SOA企业服务总线来调用。

Docker就意味着开发期环境和运行期环境一致，不会出现常见问题：生产系统说有问题，在测试环境就是重现不了。或者是，有人擅自改动了生产环境。

三、技术中台层

你一定要有主数据平台、API网关。

能通过主数据调用的就调用主数据，而不是直接调用另外一个业务系统的数据。你想调用其他业务系统的业务逻辑代码，你就必须要通过API网关来统一走，而不是直接就交叉调用了。

有了这两样东西，你的各个模块、各个业务子系统，都是简单依赖的

四、基础设施层

一定要用云服务器、云存储、云数据库、云中间件、云人工智能平台、云大数据平台、云IoT平台、云文档照片音频视频处理中间件。这些都是云化的、分布式的。这样你就不用写一个Serverless函数就打包一大堆依赖的底层中间件。 你一个Serverless Docker里面就干干净净的只有你自己的应用模块代码。

你一定要用到DevOps、灰度发布、大规模日志监控运维、大规模全链路监控运维。 这样，就不会有人为在过程中干涉，导致不同经验的人有不同的后果。

五、组织

组织也非常重要。

第一，组织要全职能组织，比如，一个团队，产品经理、UIUE工程师、架构师、前端开发工程师、后端业务逻辑代码开发工程师、测试工程师，在一个团队了，而不是干每个事情都需要产品部门、UI部门、开发部门、架构部门、测试部门来回地临时抽调人。 临时抽调协同，干的活谁也没有责任，谁也不负责，谁都临时凑合。效率、质量都极差。

第二，组织大小要控制。一定要在7-20人之间。高于20人必须拆分。 小于7人施展不开，大于20人，沟通成本协调成本都很大，而且最最导致的问题是：你因为人多，所以你会自然而然地把功能做的很复杂。所以故意给你人少，你干不了多少，所以这样也是强制约束你做不了太复杂太重型的功能。

不是人多就能出好产品。

六、过程

建议不要项目管理，不要超过1个月的项目。

最好的小步迭代是：当日内测版、每周铁杆粉丝版、每月公开版。这样的周期来发布软件。

千万别憋大招，一憋就容易把功能憋复杂了。

不是周期长就一定能出好产品。