微服务和DevOps和容器关系(12.28)

前面自己写过很多微服务，DevOps，容器化PaaS平台方面的文章，今天再梳理下几者之间的关系问题。

首先看下微服务，我们把微服务里面的一些关键组件拆分出来，其中包括了注册中心，配置中心，网关，限流熔断，服务链监控，可以看到这些组件都是可以独立的关键组件。

其次我们看下DevOps平台，在我原来的介绍里面也可以看到，我们将DevOps平台做为一个大的支撑平台，但是拆分后可以看到里面包括了敏捷研发管理，持续集成，容器化PaaS，测试平台等几个关键内容。再扩展点可能还包括了技术服务平台，后期的运维管理平台，面向生态的运营服务平台等。

微服务和API网关的关系

微服务，首先是业务组件化，从数据库到应用的全垂直化拆分。微服务一般采用SpringCLoud框架来进行开发，建议仍然是前后端开发分离的方式进行分层开发，更好的体现中台+服务+前端的思路。

谈到微服务，先谈和API网关的关系。对于微服务架构一定会用到微服务注册和管理中心，但是不一定就必须采用微服务网关。那么在什么时候需要引入网关，个人理解包括：

1. 前端有pc端，app端多种呈现方式的时候，需要引入网关，网关本身还起到类似DMZ区隔离作用。

2. 跨厂商团队协同的时候，需要引入网关，方便对不同厂商协同接口进行统一关联。

3. 中台能力需要对外进行能力开放的时候，需要引入API网关，方便对服务进行统一安全，日志，流控管理。

网关的引入增强了服务在安全，日志，流控，监控等方面的能力。注意如果仅仅是服务代理，你可能通过简单的ngnix来实现即可，但是要实现上面的诸多能力就必须要引入网关。

在谈微服务和DevOps的时候，我们把DevOps的核心能力进行拆分，包括研发管理，持续集成和交付，容器化PaaS几个关键核心能力。然后再来分析相互之间的依赖关系。

在转型到微服务的时候，个人认为实施持续集成是必须的，比如你通过jekins和maven结合来实现持续集成和持续部署，这个能力必须要用，但是你开始可能并没有实现容器化PaaS，这个影响不大，因为持续集成和自动化构建后已经解决了大部分问题，并不一定必须启用容器和镜像。

同时对于持续交付也不是必须，先做到持续集成，然后再考虑进一步做到持续交付。

微服务和DevOps平台关系

同时在实施微服务和DevOps的时候，容器化PaaS一开始也不是必须的，没有容器化PaaS我们也可以去实现自动部署能力，但是会缺失类似资源动态调度和扩展方面的能力，缺少对资源统一管理方面的能力。同时对于各个环境之间的迁移，到生产环境的持续交付也不方面。

一个容器镜像里面不仅仅是包括了中间件容器和部署包，可能还包括了其他一些配置文件，我们预安装的一些组件，要看到容器镜像完全将这些打包为一个整体，如果没有容器镜像粒度，我们在进行环境迁移的时候会相当麻烦，而且很难确保整个过程不出现差错，出现不一致的情况。

那我们考虑什么时候必须引入容器化PaaS，具体如下

1. 整个微服务的团队和模块规模都很大到一定程度的时候，必须要引入

2. 对于环境迁移和持续交付有明确的要求的时候，特别是对于持续交付的高要求

3. 对整个部署架构有明确的资源动态调度和弹性扩展需求

4. 需要更好的对IaaS平台层资源池进行统一的管理和资源分配

简单来说就是规模一大，而且需要贯穿到最终的交付环境必须引入容器化PaaS平台。来实现自动化的部署，应用托管，动态的资源管理和调度，持续到生产环境的交付。

因此对于DevOps也是同样的道理，一开始你可以没有容器化，但是后续必须要容器化，而且容器化这块要必须松耦合，即可以对接当当前主流公有云的IaaS平台，或容器化PaaS平台。

简单总结下前面阐述的内容，即：

1. 微服务架构和实施不一定需要DevOps完整体系，但是至少需要持续集成

2. DevOps不一定必须包括容器化PaaS平台，但是必须提供自动化部署的能力

3. 微服务不一定必须要API网关，再需要增强服务管控治理能力和对外能力开放时候必须采用API网关。