浅谈微服务架构搭载容器云构建历程-容器云架构

服务简史

历史总是惊人的相似，合久必分，分久必合。

我们经历了“合”：单体架构(软)、计算能力超强的小型机(硬)到“分”：分布式架构的转变，后期可能会将“分”发挥到了极致(去中心化的分布式，如区块链)，最后很可能再经历“合”：计算和存储能力超强的“智人”(边缘计算的升级，集超级计算和存储一身的人工智能)。

那单体架构为什么要演进呢?笔者认为主要体现在如下3点：

1.业务量在增加

互联网发展对应用开发提出了更高要求。业务的量级和效率提高，传统的单体架构将出现瓶颈。

2.能采集的信息越来越多

互联网飞速发展的同时，也推动了云计算、大数据、人工智能的快速落地，数据采集遍布软件、硬件，数据本身价值也得到提升。使用微服务架构恰好解决了大部分痛点。

3.万物互联

数据联通性的需求：系统间，系统与硬件之间，数据对接必须保证高性能、高安全、高标准.

微服务架构

我们已经意识到：技术架构受公司业务和组织架构影响。作为从单体架构过来的人，起初我是拒绝的，或者说担心我们的业务被拆分后出现不稳定状况。但是随着业务突然扩展，业务不断细分，敏捷开发和配套的技术方案迫在眉睫。总归是要迈出这第一步，2015年下半年，我们踏上了微服务的不归路。

技术选型

首先根据总体业务规划，我们先做了初步的技术架构规划，然后确定选型思路：

有了思路，根据我们的方法论，要根据现有的主流架构做一番比较和筛选然后才能最终敲定：

Dubbo、DubboX：优势在于全栈、服务治理的支持性强，是阿里巴巴开源且经过阿里巴巴实践的产品，中文文档很多，社区活跃。但选型时停止维护，跨语言难度较大
Spring Cloud：是Spring旗下的子项目，社区足够强大，架构本身简单方便，几乎零配置。基于RESTful API，跨语言。但当时Spring Cloud实践较少，且性能和RPC相比不占优势
Motan：是微博平台微服务框架，承载了微博平台千亿次调用业务。优势在于性能，且实现模块化、结构简单、易于使用、跨语言，但对于复杂的业务支持不够好
Thrift、gRPC：并不能算作微服务框架，自身并不包括服务发现等必要特性
Istio：Service Mesh思想，可以看作是微服务架构的一次升级，和serverless要解决的问题类似，让业务/算法与服务治理剥离，当时技术还不成熟(这个选型时后来补充的)

受限于当时技术团队的资源限制，我们根据最小阻力原则，选择了SpringCloud.spring cloud提供了开发分布式服务系统的一些常用组件，例如服务注册和发现、配置中心、熔断器、智能路由、微代理、控制总线、全局锁、分布式会话等。如下图所示：

架构替换

经过短期探索调试后准备开始试水，暂时不敢动主流业务，我们就从对外提供的一些接口服务和部分独立系统开始下手，这个阶段我们尝到了甜头，但紧随其后就是各种填坑，质疑不断，不过最后我们还是坚持下来。

构建容器云支撑

微服务初步改造后，给我们带来了一些额外困扰：

显然，我们不能通过jar包启动的方式去维护大批量微服务，而且这些服务部署在一起还相互影响。

啥是配齐?容器云+微服务

在刚引入微服务后不久，我们并没有急于替换所有业务，而是把基础运维工作做好，随后我们引入了Docker。Docker给我们带来了：

光有Docker还不够，我们发现引入Docker容器后，虽然解决了一些问题，但是还不够。我们运维起来太麻烦，各种Docker命令还有脚本，甚至我们都不知道我们到底有多少服务，它们健康状态、资源占用怎么样，当业务量激增难道我们永远都是被动且手动的去做服务伸缩么?

我们随后引入了容器编排工具：Rancher，并围绕Rancher + Docker构建了一套容器云和一套DevOps工具集(本文不做重点描述，欢迎关注后续文章)。

当我们从大量运维工作中解放出来后，我们发现，小团队也可以做大事情：

初见成果

虽然微服架构替换现有业务说起来容易，但整个替换过程持续了将近2年，到了2017年底，我们已经形成一套基于容器云和微服务架构体系的解决方案，整体架构如下图所示：