浅谈微服务架构搭载容器云构建历程
服务简史
历史总是惊人的相似，合久必分，分久必合。
我们经历了“合”：单体架构(软)、计算能力超强的小型机(硬)到“分”：分布式架构的转变，后期可能会将“分”发挥到了极致(去中心化的分布式，如区块链)，最后很可能再经历“合”：计算和存储能力超强的“智人”(边缘计算的升级，集超级计算和存储一身的人工智能)。
那单体架构为什么要演进呢?笔者认为主要体现在如下3点：
1.业务量在增加
互联网发展对应用开发提出了更高要求。业务的量级和效率提高，传统的单体架构将出现瓶颈。
2.能采集的信息越来越多
互联网飞速发展的同时，也推动了云计算、大数据、人工智能的快速落地，数据采集遍布软件、硬件，数据本身价值也得到提升。使用微服务架构恰好解决了大部分痛点。
3.万物互联
数据联通性的需求：系统间，系统与硬件之间，数据对接必须保证高性能、高安全、高标准.
微服务架构
我们已经意识到：技术架构受公司业务和组织架构影响。作为从单体架构过来的人，起初我是拒绝的，或者说担心我们的业务被拆分后出现不稳定状况。但是随着业务突然扩展，业务不断细分，敏捷开发和配套的技术方案迫在眉睫。总归是要迈出这第一步，2015年下半年，我们踏上了微服务的不归路。
技术选型
首先根据总体业务规划，我们先做了初步的技术架构规划，然后确定选型思路：
- 不绑定到特定的框架，跨语言
- 服务最好是Restful风格(风格极简，且是主流标准)
- 足够简单，容易落地，将来能扩展
- 稳定性强
- 和Docker相容性好(自动化运维)
有了思路，根据我们的方法论，要根据现有的主流架构做一番比较和筛选然后才能最终敲定：
- Dubbo、DubboX：优势在于全栈、服务治理的支持性强，是阿里巴巴开源且经过阿里巴巴实践的产品，中文文档很多，社区活跃。但选型时停止维护，跨语言难度较大
- Spring Cloud：是Spring旗下的子项目，社区足够强大，架构本身简单方便，几乎零配置。基于RESTful API，跨语言。但当时Spring Cloud实践较少，且性能和RPC相比不占优势
- Motan：是微博平台微服务框架，承载了微博平台千亿次调用业务。优势在于性能，且实现模块化、结构简单、易于使用、跨语言，但对于复杂的业务支持不够好
- Thrift、gRPC：并不能算作微服务框架，自身并不包括服务发现等必要特性
- Istio：Service Mesh思想，可以看作是微服务架构的一次升级，和serverless要解决的问题类似，让业务/算法与服务治理剥离，当时技术还不成熟(这个选型时后来补充的)
受限于当时技术团队的资源限制，我们根据最小阻力原则，选择了SpringCloud.spring cloud提供了开发分布式服务系统的一些常用组件，例如服务注册和发现、配置中心、熔断器、智能路由、微代理、控制总线、全局锁、分布式会话等。如下图所示：
架构替换
经过短期探索调试后准备开始试水，暂时不敢动主流业务，我们就从对外提供的一些接口服务和部分独立系统开始下手，这个阶段我们尝到了甜头，但紧随其后就是各种填坑，质疑不断，不过最后我们还是坚持下来。
构建容器云支撑
微服务初步改造后，给我们带来了一些额外困扰：
- 微服务过多，服务治理成本高，不利于系统维护。
- 分布式系统开发的技术成本高(容错、分布式事务等)，对团队挑战大。
显然，我们不能通过jar包启动的方式去维护大批量微服务，而且这些服务部署在一起还相互影响。
啥是配齐?容器云+微服务
在刚引入微服务后不久，我们并没有急于替换所有业务，而是把基础运维工作做好，随后我们引入了Docker。Docker给我们带来了：
- 迭代效率提升支撑：Docker 用户发布软件的频率平均快了 7 倍
- 环境可移植：Docker是一个代码运输集装箱系统，它使得通过Linux的软件开发和交付变得很容易
- 更快且更小：充分利用服务器资源，一台虚机可以跑几十个容器
- 标准统一：可实现环境甚至架构的复制性
光有Docker还不够，我们发现引入Docker容器后，虽然解决了一些问题，但是还不够。我们运维起来太麻烦，各种Docker命令还有脚本，甚至我们都不知道我们到底有多少服务，它们健康状态、资源占用怎么样，当业务量激增难道我们永远都是被动且手动的去做服务伸缩么?
我们随后引入了容器编排工具：Rancher，并围绕Rancher + Docker构建了一套容器云和一套DevOps工具集(本文不做重点描述，欢迎关注后续文章)。
当我们从大量运维工作中解放出来后，我们发现，小团队也可以做大事情：
- 小团队作战，敏捷开发方式，替换其他业务
- 解决方案打包，一键部署
- 抽出人手构建我们同等重要的DPaaS平台
- 部分业务变化快的模块快速优化甚至重构