服务治理的技术血脉

当今有很多流行的概念：SOA、领域驱动设计、微服务、服务网格、云原生。而他们之间有什么联系呢？这就需要了解服务治理的技术血脉。

无服务治理时代

记得07年刚毕业的时候，工作里动辄就是上百人月（人月是工作量单位，比如120人月就是120个人要做一个月可能完成的项目，那如果投入10个人，就要做1年）的项目，整个项目都放在一个巨大臃肿的单体应用中，服务之间的通信主要靠内部调用。外部调用就是访问本机的数据库。所以那时候没有人考虑服务间的通信问题，也谈不上服务治理。

是东西就要坏的，强大稳定的数据库也不例外。在无服务治理时代，数据库挂了，可以靠DBA的个人能力手动切换到备份数据库。就一个服务，切换成本还好。

服务治理启蒙时代

随着规模的增大，沟通和维护成本的提高，服务从单体应用转向垂直拆分架构。数据库故障，涉及一堆服务都需要修改数据库连接到备份服务器。这就需要将这种状态管理的工作自动化。

10年时，我负责承担整个项目的基础架构工作：用socket写一个心跳检查检测数据库是否正常，如果发生异常则发送数据包到各个应用程序让应用程序自动切换到备份数据库。记得刚开发好的时候不稳定，有次出问题了：我去！一屋子人都站起来了，眼巴巴的看着我。

自己造的轮子总是免不了有坑，要用成熟的技术。用了一段时间我自己造的轮子后，业界的轮子PK战役中，zookeeper脱颖而出。它以方便的数据管理和令人头大的一致性算法让人印象深刻。这就是早期的命名服务。可以实现最基本的服务注册、发现和路由功能。

第一代服务治理

服务越做越大，分工也越来越细。前后端分离了，07年前，几乎所有程序员都是全栈工程师。而现在前端还分为IOS、Andriod、H5、小程序和网页端的。服务间可共用SSO(单点登录)服务。各个端的接口稍有不同，但是可以共用底层服务和存储。这就产生了分布式架构。人们发现1996年由Garnter提出的一种设计范式：面向服务架构SOA是分布式架构的一个不错的解决方案。

SOA是一个组件模型，它将应用程序的不同功能单元进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。实现了这个功能的代表性框架就是Dubbo。

Dubbo建议使用zookeeper来做注册发现，提供RPC组件进行服务间通信，并且提供了监控中心来对服务进行监控。

第二代服务治理

SOA本质是一种中心化的架构，这种架构随着项目复杂性、多变性增加，弊端进一步凸显出来。Martin Fowler等一批人就提出了要去中心化、进一步将模块变小的微服务架构。而以怎样的原则来将模块变小呢？Martin Fowler又提出了领域驱动设计DDD的方法，核心就是从业务视角来对服务进行拆分。

微服务的出现，服务有更大按照需求来选择技术栈的空间。但是都需要注册发现、服务间通信，监控。并且都想知道调用的上下游情况，如果遇到流量突增、非法访问等，希望可以统一的进行治理。需求驱动，产生了支持多语言的一站式解决方案，例如：Spring Cloud。

Spring Cloud使用Spring Cloud Netflix Eureka来代替Zookeeper，使用REST API来代替RPC，同时提供断路器等功能。

第三代服务治理

随着第二代服务治理框架功能越来越强大和服务量增多，特别是云原生崛起之后，客户端也越来越重，通信成本和稳定性都受到挑战。云服务化孕育出云端微服务架构，它的核心理念是服务微自治。

人们将这些通信、监控等与应用无关的功能从应用中剥离出来作为单独的进程使用，这种被成为sidecar的代理进一步简化了开发。而Spring Cloud之前的一些功能被抽象为Data Plane和Control Plane。这就是服务网格。

回答文章开始时的问题：当今有很多流行的概念之间有什么联系？

我的理解是：SOA是分布式架构初期的解决方案，DDD是微服务架构的解决方案，服务网格是云端微服务架构的解决方案。

目前有很多公司在对外宣讲的时候称自己公司的服务治理框架为自下而上的服务网格。如果你看懂了这些文章就不难理解原因了。毕竟，像Spring Cloud这种趋近成熟的服务网格实践还有很长的路要走。