本文作者：汪照辉 王作敬 中国银河证券股份有限公司 信息技术部IT研发中心

容器已经火了好几年，Kubernetes似乎也要一统江湖了。基于容器技术的容器云在过去的2017也是高歌猛进，势不可当。各个容器厂商呈现春秋争霸之姿、战国争雄之态。但是采用容器云之后做什么、怎么做，似乎并没有太多的人想明白，更多人只是纠缠于CaaS、PaaS等概念上。容器云实施也好像没有什么指导原则和理论，所以仔细看来，各家容器云其实大同小异，都是基于开源的容器编排调度框架，很少有自己的思想，至多是技术上的修修补补，甚至为了和开源版本的兼容，都不敢于调整开源框架，不敢做创新。

对于那些声称对于开源Docker或Kubernetes社区有几万几十万行代码贡献的厂商，我们也只能笑笑。你们的贡献和我们的实际业务需求并不成正比。不是我们不选择你们，实在是你们都是以社区为中心，不是以客户需求为中心，难以满足我们需求。

没有理论指导，缺少实践经验，只能摸着石头过河。在跟一厂商沟通的时候，我们谈到为什么不把权限管理拿出来作为一个独立的模块，他们也一直在纠结，要支持权限中心能力，就需要做相对大的调整，不调整又受限于这种紧耦合的设计，难以支持灵活的需求。我们看来，我们做项目做产品最终目的是为了使用，为了简化我们的工作，提高效率，不是为了某些热炒的技术。我们也说过，容器云是基础设施，对终端业务应用客户来说，他们不关心基础设施采用的是不是容器技术，他们更关心的是他们的业务服务。所以，作为容器云厂商，如果想在群雄争霸中胜出，那就需要你有足够的魄力来改变，走在前面，而不要跟在别人屁股后面亦步亦趋。

容器云有了开源基础，但还不足以应用于企业生产。所以我们需要考虑容器云在企业生产中的实施。微服务思想可以拿来借用下，使用微服务思想来指导容器云在生产中的实施。

一、解耦合

微服务的核心思想是解耦合，化大为小、化繁为简！容器云实施时，架构设计首先要考虑各组件模块之间的解耦合。其实我们在前面的文章《云计算杂谈》中已经谈到容器云架构设计的问题。微服务架构设计是相对于传统单体应用架构的设计方式来说的，传统单体应用把所有的功能都糅合在一起，所以显得大而重，其实往往这些单体应用的很多功能花费开发人员大量精力开发出的，可能从来没用过，或者很少用。所以微服务架构要把这些不相关的功能解耦合，独立出来；相关的功能也尽可能松耦合。比如每个单体应用都会有的日志、监控、统计等功能要把它们分离出来，成为独立的松耦合日志模块、监控模块、统计模块（或叫日志服务、监控服务、统计服务）等。容器云的实施也是一样。可以把容器云中的权限、多租户、日志、监控、健康检查、资源、网络、存储等等分离出来作为独立的服务，各服务之间是解耦合的，服务粒度的划分需要考虑实际的需求。比如日志，可以分离出来成为一个集中日志中心，不只是容器云平台，其他系统、其他应用的日志都可以集中到日志中心，通过多租户权限来管理自己相应的应用或系统日志。

我们讨论容器云、微服务的时候，更多看到的是容器云平台的特性非常适合微服务的部署和管理。透过现象看本质，学习微服务，学其思想。道理都是相通的。使用微服务的思想，来构建解耦合的、灵活的容器云，所以容器云和微服务又是相辅相成的。彼此自治、独立而又相互联系，这就是微服务的理念。

二、共享

采用服务化，一个很重要的原因是为了实现服务共享。把一些公用的功能提取出来，作为共享的功能服务供多个系统或应用来使用。前面我们的文章中也谈到了权限中心、统一认证中心、服务配置中心等设计以及日志中心、监控中心、告警中心等想法。为什么会有这样的设计和想法？就是基于共享的理念。我们不希望每建一个系统就开发一套日志组件、监控组件、告警组件，不希望每个系统都有自己的一套用户管理、角色管理、权限管理、认证管理等功能，这些功能的从思想上都是一样，方式上功能上大同小异，为什么不能把这些常用的、通用的功能提取出来作为一个通用的服务或组件，供所有的服务或应用系统使用？这就实现了最高层次的共享，也实现了数据格式等的统一。

微服务都有自己独立的数据库，所以能从数据层实现数据共享，提供唯一数据源。在容器云架构设计时，也可以考虑这一点，每个模块的数据可以独立管理。不同模块之间通过接口通信连接。这样，这些模块就可以被不同的应用不同的服务使用。就像日志，每个应用都会使用，使用统一的接口，调用日志服务，可以把所有的应用日志、平台日志、系统日志等分类采集到日志中心，基于多租户权限控制，实现统一的日志数据管控。

三、清晰的服务边界

微服务独立部署，有清晰的服务边界。实施容器云组件服务也需要定义清晰的边界。其实就像我们设计的服务配置中心，仅仅是提供对应用服务的全局变量配置管理能力，并不对容器云平台的配置进行管理。因为这是两个层次的需求。容器云平台是基础设施，其上部署的应用服务是面向终端用户的，是由应用运维人员来运维的。用户并不关心这些应用服务部署在什么地方，应用运维人员和平台运维人员的角色是不一样的，应用运维人员并不关系平台的配置需求。如果也想为容器云平台提供一套配置组件，那可以基于容器云的实现来分离出一个容器云平台配置服务。我们不建议把这两项能力合二为一，否则不但会带来组件维护的难度，也会给使用者带来理解和使用的难度。

四、统一的API，插件化

微服务通信使用统一的协议、API，但实现这些API的技术、方式、语言等等可能完全不一样。容器云各组件之间的通信和集成也需要提供统一的接口API，可以方便的实现插拔式的组件集成和移除、替换。

比如日志中心，目前我们采用开源ELK组件，目前ELK的能力足以满足我们对日志采集、存储、查询、分析的需求。但并不代表着我们一直能用ELK。可能有更好的开源组件，也可能某天想换用更强的商用组件。如果有统一的API，实现组件集成和替换将会非常便利。

我们也一再强调过，不希望以项目的形式来实施容器，希望以相对成熟的产品来实施容器云。作为产品，就需要考虑通用性、普适性。所以统一的接口设计，插件化的集成方式将会非常便利的协助完成容器云实施，也是产品成熟度的一个评判纬度。

五、自治

微服务的思想是每个微服务自治、有自己独立的数据库。这就让我们在数据管理和数据治理上能实现单一的数据源。对一个企业来说这是非常有价值的。从数据层就实现了数据共享，比传统ESB的实现可就简单多了。同时也不需要做繁琐的数据转换、数据清理、数据完善等工作了。消除了数据的不一致、不完整、冗余等等。基于这些数据的基础上的微服务，提供更精确的数据支撑；基于这些数据基础上的数据统计、数据分析、数据报告、事件处理等能更好的支持公司业务的运营和研发。

六、去中心化、分散治理、分散管理

最近微服务的Serverless概念又很火热，Serverless就是去中心化，没有Server。当然只是相对的，并不是真的没有Server。其实我们觉得容器各组件服务也类似，每个组件服务是独立自治的，但组件服务之间是平等的关系，有联系但不是连体。再拿人类比，每个人有自己的大脑——控制中心，但个人与个人之间就没有了Server，不过人类社会关系中还是有这样那样的团体、单位等等，又是中心化的形式，有一个Server。如果全部祛除Server，那就成了无政府状态，也不现实。所以Serverless都是相对来说。

日志、监控、配置等等组件服务都是独立自治的公共服务，可以分散部署，分散管理，分散治理。单个组件自成一体，不同组件平等、协作来共同完成客户业务需求。不只是容器云，只要遵循统一的服务接口，都可以方便的和这些自治的、共享的组件服务集成。

七、容器云控制节点宕机不能影响云上微服务的运行和正常使用

微服务的思想要求彼此自治，不能因为某一点的故障导致整个系统崩溃。所以作为容器云平台，其控制节点可以高可用，但即便是不配置高可用，在其宕机时，除了不能提供编排调度管理等功能，不能影响到容器云上已经部署的服务的正常运行和使用。说到底，Kubernetes等只是个调度管理工具，控制节点的高可用并非核心需求，所以这一块需要和容器引擎Docker松耦合，容器一旦被部署了，在运行时过程中，如果控制节点宕机，控制节点提供的调度管理、健康检查等不可用，但容器引擎不能受影响，容器中的业务服务不会受影响。已经发生了众多的公有云平台故障，导致所有的服务不可用，这是不可接受的。所以在实施容器云时，一定要确认控制节点和业务节点不能相互影响，不能因为某一节点的故障导致业务应用的不可用。