微服务治理发展历史—单体架构

IT 治理与服务治理的关系

IT治理的概念最早是由 IBM 引入中国的，所谓“治理”，在《汉语大词典（简编本刊中的解释是“整治、修整”，从字面上看包含了对被治理对象的问题梳理及改进优化的意思。按此理解，企业 IT 治理可以理解为对企业 IT 问题的梳理及改进优化 目前业界比较普遍认同的定义IT 治理是描述企业或政府是否采用有效的机制，使得 IT 的应用能够完成组织赋予它的使命，同时平衡信息化过程中的风险，确保实现组织的战略目标的过程。

IT 治理本质上是为业务服务的，治理的最终目标是保证企业 IT 能力建设能够适应企业业务的变化发展，为业务保驾护航，而不是“拖后腿” 1.1 比较形象地描述了企业业务与 IT治理的关系。

IT治理规定了整个企业运炸的基本框架，涉及IT的所有方面，包括IT组织治理、IT管理效能治理、IT架构治理、基础资源治理、应用/服务治理、数据治理等领域的治理。

服务治理是IT治理的一部分他重点关注服务生命周期的相关要素，包括服务的架构、设计、发布、发现、版本治理、线上监控、 线上管控、故障定界定位、安全性等

在服务 体系中，由于服务的提供者和服务的使用者分别运行在不同的进程中（甚至在不同 物理节点上〉，并由不同的团队开发和维护。团队 的协作和服务的协同，都需要进行大量的协调工作。协调工作越多，复杂度越高。任何事物，一旦有了复杂度，治理的需求就会随之而来，通过治理，为协调工作立规范、打基础并时时监控，不断提高协调的效率，以期降低复杂度，规避风险，这就是服务治理的由来

服务治理发展历史

1.2.1 单体架构及治理

2.1 单体架构的进化

一个系统的发展壮大总是由其业务驱动的，系统的访问量。数据量、业务的复杂程度直接决定了系统的应用架构 。一个小网站系统或 个普通的企业 Web 应用在访问量和数据量较小时，往往所有的功能模块都打包在 个工程中，并最终发布为 个部署包 CJava 中是 war 应用包），并部署在 Web 容器中运行，如图 1.2 所示

随着业务的发展，系统越来越复杂，有的开发人员习惯在 JSP 页面上实现所有的功能，有的开 人员则注重把一些通用功能抽取为 Jav aB ea 不同开发人员的不同开发风格会给系统的维护带来严重的影响。这时候，我们开始思考对功能模块进行分层设计，以便对功能模块的设计提供统一、易于维护的标准模式，这样也能让系统内部单个模块的设计有效地解祸。在分层设计中，应用最普遍的是 MVC 设计模式，最典型的 MVC JSP + Servlet + JavaBean 模式，但这种组合的约束性太弱，不易形成统 的规范 对于模式的应用，最好的途径莫过于直接使一些基于模式设计的、具有一定约束性的框架（ Framework ）， 利用别人搭建的 舞台(Framework ）来进行表演（开发应用〉 这个时期很多公司都在开发并分享自己的框架，大浪淘最终慢慢沉淀下来 些设计合理、普及性广泛的框架，比如 Java 中的 truts 1/ SpringMVC,Go 中的 Django Ruby 中的 Rails 等。

基于这 MVC 框架，将模块内偏向展示的部分抽取成独立的视图层（ iew ，将负责请求处理流转控制的业务代码独 为控制 Control ，也叫活动层），为了防止控制层太重，还可从其中将负责具体业务逻辑的代码抽取为一个独立的服务层（Service），以集中操作文件、数据库等资源。各层之间弱耦合，只有一个统一的业务模型（Model）贯穿前后。这样，一个功能模块的开发就可以分别由团队内的不同人员负责。这是系统微观方面的拆分，如图 1.3 所示

使用 MVC 框架，一定要遵守该框架的规则，它有 定的强制性 MVC 框架使应用程序输入、处理和输出分开。使用 MVC 的应用程序被分成 个核心部件：模型、视图和控制器（可以从其中再隔离出服务），它们各自处理自己的任务

单体应用的开发和调试都很简单，部署也相对容易，只要控制好 Sess ion 在不同节点的共享问题（可以采用前端 Cookies 缓存数据，也可采用后端的数据库或统一缓存中心来缓存数据〉，只需要把打包应用复制到服务器端，再结合负载均衡器就可以轻松实现应用的扩展。在早期，这类应用运行得很好。由于系统架构及部署架构都比较简单，治理方面的需求并不强。

这个时期的复杂度，主要来自于系统功能不断扩充后，系统膨胀导致的开发复杂度上升，这个复杂度既体现在单个功能模块的前、后端的糯合度上，也体现在模块间的依赖和模块的复用性上。

1.2.1 .2 组件库及真治理

架构分层，尤其是类似MVC 等框架的导入，解决了单个功能模块的复杂度问题。在模块的复用性上，将一些基础的或者通用的功能模块独立抽取出来，形成独立的组件库，组件库的各个组件可独立维护，并按需组装到不同的应用中，基于组件库的开发模式

组件 的出现有效改善了单体系统开发的复杂度，诸如基础运行框架、认证、授权、资源（文件 DB 、缓存等〉等对外无依赖且自治的平台和组件可以被抽取出来，独立地按工程开发并发布为独 础组件。而更上层一些靠近业务的通用模块（可能会依赖其他组件 〉也可以抽取为独立工程并发布为通用组件。有了组件库之后，应用的相当一部分能力集成现有组件即可，其工程的体量直接降了下来 ，业务开发人员就不需要再关注“一大坨的”底层功能代码

有了组件库之后，开发的复杂度从应用转移到了组件库，尤其是在组件的数量攀升之后组件的复杂度来自多个方面：①每个应用会依赖多个特定版本的组件；②每个组件，尤其是通用组件，可能会依赖其他组件：③每个组件会分多个版 。最终 ，应用和组件之间的依赖关系会形成如图 1.5 示的状况。

可以看到，应用和组件之间的依赖及组件之间的依赖形成了 个网状的关系，而组件的版本又增强了这个依赖的复杂度。大量的应用、组件、组件版本最终形成了一个复杂的直接及间接的依赖关系。有了复杂度就有了治理的需求，这个时期的治理需求主要是对组件库的治理。

笔者之前曾在一家大型 RP 企业负责组件库的构建及治理工作，要定期给出组件治理报告，分析组件的状态及依赖，包括哪些组件是核心组件（依赖最多） ；组件依赖是否合理、是否有循环依赖；哪些组件版本可以归档、不能再被使用：组件版本升级涉及多少线上应用、关联组件是否也要同步升级； 等等。通过组件库的治理，可以有效控制功能的版本，防止版本失控，从而降低应用的维护难度及成本

1.2.1.3 单体应用的不足

通过架构分层及组件库，虽然有效降低了应用系统的复杂度及维护成本 但随着业务不断发展， 个简单的应用总会随着时间的推移逐渐变大 在每个迭代周期中，开发团队都会面对新“故事”，然后开发许多新代码。长此以往， 个小而简单的应用会变成一个巨大的“怪物”笔者曾在入职一家新企业的时候，接手了一套老平台系统的维护工作，这套百万行代码的系统经历了无数程序员之手，功能巨多，代码纵横交错。看了两个星期代码之后，笔者直接崩攒了，不得不基于 IDT 写了一个代码梳理工具，很多单体系统最终都会发展成这样一个“怪物”

一旦应用变得庞大又复杂，对任何接手的开发团队都是个“噩梦”。这时，没有一个开发者能够通盘了解它，团队对系统的控制能力降低，我们不知道修改 Bug 和添加新功能是否会引入不可测的风险，修改 行代码都会瞻前顾后、顾虑重重。这种背景下，程序员很难有什么成就感可言，团队的稳定性也就可想而知了

单体应用 会降低开发速度，虽然可以拆成组件，但最终依然还是要合并部署。应用越大，启动时间越长。笔者曾经见识过 个银行的内部系统，启动时间居然超过了 20 分钟，其间涉及大量组件的初始化工作。如果开发者需要经常重启应用进行调试部署，那么大部分时间就要在等待中度过，生产效率会受到极大影响

单体应用在不同模块发生资源冲突时，扩展将会非常困难。比如，一个模块主要进行业务

逻辑计算，应该部署在计算型主机上；而一个缓存模块则更适合部署在内存型主机上 如果这些模块都部署在 起，可用硬件的选择面将会非常 ，成本也会直线升高

最后 ，单体应用一旦长大了，容易“尾大不掉”，很难进行架构升级和技术优化 无论是时间成本、人力成本，还是替换成本，都很高昂。这是 个无法逾越的鸿沟，这个时候，任何治理手段都会失效，往往最终会为最初的选择付出昂贵的代价

总结单体应用的发展历程： 初的“小而美”的核心业务应用，会随着业务的发展慢慢成个难以理解的“大而全”的“怪物” 单体的复杂度导致系统可 性降低，任何人在此系统上进行扩展都会投鼠忌器，更谈不上升级技术和提高开发效率了。最终的结果是无人愿意接手此应用，敏捷开发和部署也无从谈起正是由于单体应用的种种弊端，所以在业务发展的过程中，往往会对应用按更细化的业务进行拆分，拆成独立部署的不同的小应用，如图 1.6 所示。这时候，原来的内部调用关系就变成了跨网络的远程调用，系统间的集成需求也就浮上了 水面，企业级应用和互联网应用由于需求的侧重点不同，走出了两条既有交集、又有很大差异的路。