前言

最近在读的一本书籍：《Kubernetes in Action 中文版》，豆瓣评分 9.1，恰好部门的自研 Paas 平台架构就是 Kubernetes。其实相关书籍资料非常多，比较经典的还有《Kubernetes 权威指南》，豆瓣评分也是颇高。

运维架构演进

迄今为止，软件行业一共经历了 3 次运维架构演进过程：单体应用架构->微服务架构->容器化架构，而我从 2018 年进入软件行业以来，加入过的团队都恰好符合这三个演进步骤之一，所以感触颇深。

1、单体架构

单体架构比较初级，典型的三级架构，前端(Web/手机端)+中间业务逻辑层+数据库层。这是一种典型的 Java Spring mvc 或者 Python Django 框架的应用。

单体架构的应用比较容易部署、测试， 在项目的初期，单体应用可以很好地运行。然而，随着需求的不断增加， 越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。

实战经验

2018 年初，当时我加入的是一个只有 10 个开发的小团队，遇到发布的情况的打法也相当简单粗暴，见如下流程图：

可拓展性

运行一个单体应用，往往要提前预估今后业务发展所需资源，准备好一台高性能服务器。

• 垂直扩展：通过 CPU、内存、硬盘等系统资源去扩展服务器，成本越来越高昂

• 水平扩展：应用程序要改动很大，甚至一些组件，如关系型数据库不太可能做水平扩展

总结一句话，单体应用的任何一个部分不能扩展，整个应用就不能扩展。

2、微服务架构

微服务架构，主要是中间层分解，将系统拆分成很多小应用（微服务），微服务可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上。当应用的故障不会影响到其他应用，单应用的负载也不会影响到其他应用，其代表框架有 Spring cloud、Dubbo 等。

微服务通过 HTTP、AMQP 的同步或异步协议，支持微服务之间的通信。

任何微服务可以用最合适业务的开发语言去实现。

确保 API 不变或向前兼容，就可以单独部署发布。

实战经验

后面我加入一家 tob 的企业，也经历了微服务体系架构的转变，但是受限于开发能力的良莠不齐，简单粗暴的拆分微服务，带来的是无休止的 API 功能拓展，以及定位 Bug 的扯皮。

随着 tob 客户的不断增加，运维上线的负担呈指数级增长；以前的单体架构只需要发布一次，现在各个微服务组件都要发布一次，有时启动失败还会阻塞发布流程，可谓相当疲惫。这时我们还没有引入 Kubernetes，据说后面也在逐渐往容器化道路转型了。

可拓展性

• 我们可以选择扩容某些微服务，同时保持其他微服务维持原来的规模（Good！）

• 微服务独立部署和发布，可以单独迭代

弊端

• 微服务组件数量增加时，部署应用在哪个服务器上面，将会变得越来越难抉择，同时也会变得错综复杂

• 环境依赖差异，因为微服务的独立性，导致了微服务可能存在依赖的差异性

3、容器平台与 DevOps

这些年，越来越多企业认为：让同一个团队参与应用的开发、部署、运维的整个生命周期会更好。这就是 DevOps 实践：开发者 &QA&运维团队彼此之间的合作贯穿整个流程。

而让 DevOps 成为可能的关键，就是容器平台技术的飞速发展，尤其是 Kubernetes；曾经业界也有不同声音，认为“docker+marathon+mesos 这样的开源分布式资源管理框架会更灵活并定制”，但是很快 Kubernetes 抢占了它们的市场份额。

可拓展性

• 开发者专注应用于业务：自行部署应用上线，而非经过运维人员操作；同时部署应用，开发者不愿意知道具体的数据中心底层设备和硬件架构的理解；

• 系统管理员和开发者各司其职：运维团队本身不需要关心所有应用组件之间的暗藏内部依赖，而是专注于系统安全和使用率；

未完，待续..