之前以嘉宾身份参加了 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 太低，考虑合。
代码行数太多，考虑拆。
一个需求跨业务领域的工程太多，需要考虑合。
总结
参加这种线下大会，除了能学到不少技术干货，深入讨论一些技术问题之外，我们还能认识同领域的不同大佬，和他们深入交流。
程序员，最容易活在自己的世界里，走出去，和各行各业的朋友一起进行思想的交流、碰撞，我们才能看到不一样的世界，走得更远。
