单体架构走天下，服务治理是扯蛋

之前以嘉宾身份参加了 ITPUB 主办的 SACC 中国系统架构师大会，对于服务架构治理的一些观点分享给大家。

在嘉宾老师分享进行到一半的时候，台下有个测试同学分享了他的观点：

很多时候服务治理，其实增加了系统的不稳定性。本来运行了好几年的稳定系统，因为做服务治理，出了故障。 还不如原来的单体架构，简单、稳定。

这一点的确是其实是很多公司的问题。

盲目追求技术的先进性、框架的高大上，忽略了实际，最后导致花了钱、花了时间，最后做出来的系统就是一堆垃圾，根本不能用，还不如什么都不动。

所以，在分享之前，提醒大家一句：没有最好的架构，只有最适合的架构。

当你的确不得不去做服务架构治理的时候，那么下面几个点，希望对你有参考意义。

1、为什么需要服务治理？

业务发展期，老板唯一的要求是快，业务快速上线、快速迭代、快速复制。

业务发展稳定之后，必然累计大量的服务。这些服务，工程缺规范、服务规划混乱。

大量垃圾代码、混乱的服务交织在一起。导致故障频发、编码效率低、业务交付效率低。拖累业务发展，维护成本高。

这些的本质是熵增定律：在一个孤立的系统内，如果没有外力做功，系统的混乱程度会不断增大。

2、怎么定义算是好的架构？

一个原则：高内聚、低耦合。

具体再细分一下：简单、敏捷、解耦、可读性好、可切面、可迭代、可演进。

另外，最好考虑服务之间的重要性，把重要的模块和不重要的模块分开，方便治理。

3、业务架构膨胀过程中遇到哪些痛点问题？

服务过微

服务过微说的是我们的服务拆的太细。服务过微会导致人力成本上涨、发布、回滚等开发效率的降低。

对于互联网公司而言，人力是最大的成本。

服务过微会导致人与人之间的协作变得更加困难，另外，一个人维护过多的项目也会降低开发、运维效率。

同时，会导致每个需求的开发，需要更改更多的工程，导致发布&回滚效率的降低，从而增加成本。

如何在全司范围内推动服务治理

1、量化、数字化服务治理这件事情的重要性、优先级、双方可能的收获。

另外，需要考虑具体业务部门的阶段，是业务突破阶段还是业务平稳阶段？

2、对业务目标的影响。服务劣化，首先对于业务部门也是有影响、有成本的。具体来说，服务劣化，一定会影响研发效率，从而影响业务指标的达成效率。

3、让利。对于整个服务治理的过程中来说，业务部门是配合基础架构部门进行推进，我们一定要感谢业务部门的配合，没有他们的配合，基础架构部门干不成这件事。我们需要让利给配合的业务部门。

推进的过程中，我们可以找和我们关系的一个业务部门进行推进，拿到结果之后，推广到其他部门。

4、排序。按照治理情况，给所有业务部门进行排序，一直排在后面的部门，一定是有压力的。

3、服务治理原则

架构治理的本质方法：领域划分、服务分层、依赖拆分。

将低内聚(工程包巨大、有效引用包很低)、高耦合(JAR包依赖严重、跨部门依赖多)的架构，通过领域设计重构、依赖大包治理结合的方式 进行治理，从顶层进行架构领域规划、服务优雅设计，将腐化的架构治理到清晰的架构(高内聚、低耦合)。

领域和服务的怎么划分呢？应该遵守什么原则呢？

纵向划分业务领域、横向进行服务分层。

1、纵向业务领域划分

• 互斥：垂直领域间互斥
• 重用：不重复建设其他领域功能
• 分层：领域、子领域分层清晰

2、横向服务分层

• API 服务：面向端请求的编排服务，不含业务逻辑，有的公司也称之为业务网关。
• 聚合服务：面向业务场景的组合服务，重业务逻辑。
• 领域服务：面向数据储存的数据服务，储存一一对应。

举个例子：我见过一家公司的订单中心是这样设计的。

按照这样，进行服务分层之后，治理起来就会很容易。

比如：你需要限流，只需要限制 API 服务即可。

如果你需要更换 DB，只需要修改 DB 层的服务即可。

要从哪些方面治理架构？

治理服务架构，需要考虑稳定性、业务支撑性、长期可靠、不可盲目跟风。

技术是为业务而服务的，适合的才是最好的？

那么，什么情况下适合上微服务？

从两个方面说，第一个是人：需要考虑具体的业务，toB、toG 的大部分场景，是不需要考虑微服务的。

第二个是场景：QPS 特别小的场景，比如：QPS 〉 1000，日 PV 量 〉 1000W 才需要考虑微服务。

什么时候需要合并、什么时候需要拆分？

CPU、IO 太低，考虑合。

代码行数太多，考虑拆。

一个需求跨业务领域的工程太多，需要考虑合。

总结

参加这种线下大会，除了能学到不少技术干货，深入讨论一些技术问题之外，我们还能认识同领域的不同大佬，和他们深入交流。

程序员，最容易活在自己的世界里，走出去，和各行各业的朋友一起进行思想的交流、碰撞，我们才能看到不一样的世界，走得更远。