作者围绕其这些年在OpenStack、Kubernetes、Microservice、DevOps、Cloud Foundry、ELK等云计算相关领域及技术的实践，从微服务和DevOps两方面着手，旨在为两者的落地提供一个快速可行路径。针对这“说说还可以，一深入讨论就吵架”的热点概念，详解了在产品研发过程中的思考与实践，通过多维度的架构与技术剖析，与大家深入沟通云计算的企业级落地思路。本文是从作者这些年的经历与实践出发的总结，也欢迎感兴趣的同学参与交流、保持沟通与学习。（备注：作者微信二维码详见文末）。

（一）服务与DevOps的认识

现在见客户就会聊微服务、聊DevOps、聊容器，但这种热点概念，真的是“简单聊聊可以，一深入就吵架”，比如以前谁问我传统应用该怎么拆分，我还会说一堆，现在基本上对于这种开放型问题都不敢回答了，怕“没朋友”。

我简单说说我对微服务和DevOps的认知吧：

第一个就不说了，第二个垂直架构，典型的比如SSH框架，帮大家考虑了模块化、MVC等，但并没有考虑服务化。

第三个是分布式架构，以SOA为代表的这类技术已经热了很多年，也很成熟，也是目前很多企业架构的主体支撑。

而第四个以微服务架构为支撑的技术虽然在一些先进企业或互联网公司已经运用，但从生态上来看，还有很长一段时间要走，其更强调在DDD下的业务服务自治性及原子性。

“DevOps”通常指的是新兴的专业化运动，这种运动提倡开发和IT运维之间的高度协同，从而在完成高频率部署的同时，提高生产环境的可靠性、稳定性、弹性和安全性。

其概念也特别多，简单浏览下就可以了：DevOps运动的起源通常被放在2009年前后，伴随着许多运动的相辅相成和相互促进——效率研讨会运动，特别是由JohnAllspaw和Paul Hammond展示的开创性的“一天10次部署”，基础设施即代码”运动(Mark Burgess和LukeKanies)，“敏捷基础设施运动”(Andrew Shafer)，“敏捷系系统管理(PatrickDeBois)，“精益创业”运动（EricRies），JezHumble的持续集成和发布运动，以及Amazon的“平台即服务运动”等这些运动的相辅相成和相互促进而发展起来的。

那云计算、微服务、容器这些概念或能力之间到底是什么关系呢？其实这个主要看大家的方向了，结合我所面临的客户以及IT现状，我的理解是这样的：

1.                  云基础平台作为底层支撑，既可以是Docker、Unikernel这样的容器技术，也可以像vmware或OpenStack这样以VM为管理单元的方式，旨在为上层提供有SLA能力的资源池管理与调度；

2.                  DevOps作为一层可选平台，以流程自动化、工具自动化为主要手段，通过长期的积累与优化，为最终业务交付提供更敏捷、更数字化的能力；

3.                  历史系统与微服务在企业会长时间并存（BiModal），不要试图一步到位，我所经历的企业客户中，都是从部分外围应用开始试点，甚至是先拆应用、再拆数据这样循序渐进的。

（二）平台级的实践与支撑

先和大家说说我们的平台具体在做什么：

这个定位（非市场定位）讲起来比较拗口，“用微服务架构，做云计算DevOps平台，支撑上层微服务的全生命周期管理”。

这里有个鸡生蛋、蛋生鸡的问题，那我们还是通过制定微服务的规范以及一部分配套工具，基于这些开发了第一版DevOps云平台，将其作为后续版本的生产线使用。过程中对康威定律又有了进一步认识，尤其是运用在异地协作和技术选型上，团队能力、异地松耦合是必须考虑的维度。

先将平台用到的一些技术栈列出来：

图中标红的是目前我们已使用的，相信大家不难看出来：

1.                  我们主要是走的容器云这条线（当然传统的也是支持的），以Kubernetes为容器管理与调度的框架，结合Flannel网络、Ceph存储形成底层基础支撑

2.                  微服务方面使用SpringBoot作为载体，引入了Netflix的部分框架支撑微服务调用、配置

3.                  在全生命周期中，还支持了文档、Mock、自动化测试的能力，以便微服务架构下的快速交付

4.                  在监控方面采用Journald采集，Fluentd作为server、同时通过索引及时序库支撑数据分析及展现

这里有三个想法与大家共勉：

1.                  架构师的角色转变，从原来的技术货架的搭建（加法）到现在海量技术中选择最合适的（减法），对能力的要求更高

2.                  个人全栈已经不再多见，而团队全栈却越来越重要，学习型组织将是未来衡量团队能力的一大标准

3.                  框架能力的阳性与阴性，同样是结合现在海量技术来看，测试是必不可少的，但业务场景的多变往往会造成数据的片面性，比如Flannel的UDP和Vxlan模式（就像体育赛场上一样，阳性不好，但伪阴性就更糟糕了）

接着分别从微服务和DevOps方面来看看我们的一些关键设计和想法，先说说微服务架构：

当然微服务架构中重要的不仅仅是上述的5个能力：

1.                  服务的隔离与互通

2.                  伸缩与漂移

3.                  升级与回退

4.                  熔断与降级

5.                  服务注册与发现

上图亦可理解为是核心概念模型，面向的问题是这样的：

·                     有些企业会考虑生产上VM，开发测试上容器；

·                     有些企业需要开发测试预发上线四套环境，有些只要两套：

·                     有些企业环境间要求完全隔离，有些只要逻辑隔离；

·                     有些企业要求对接下层资源池，有些则完全没有资源池的概念；

·                     …...

那概念模型上我们怎么办？上图的核心是业务运行及namespace的设计，下层无论资源有没有池化，都需要加一层Namespace的管理，这个管理有很多目标，比如隔离，再比如池化。

然后紧接着是pod，这个概念参考了Kubernetes，在微服务运行时，一直强调一个业务的独立性，比如一个业务，其应用及数据库是绑定的，且与其他业务隔离。那我们认为这种就是一个pod（豌豆荚），体现的是一个独立业务（微服务）。

一个pod无论内部如何，一般是跑在一台宿主机的，业务内部尽量本地调用，pod可以包括多个进程，也可以包含多个容器，也就是上图的pod与process的关系。

从可靠性及性能考虑，pod必须是集群的，所以一个pod可以有多个副本，也就是上图的pod与replication的关系。

最终业务要能对外提供能力，类似一个集群对外的统一发布地址，也就是上图的service的概念，service是外部的访问入口，并拥有一定的负载均衡能力。

下图是运行时的调用过程示意：

互通要求的是“可达、快速可达、安全并快速可达”。一个微服务内部可采用本地方式，而微服务之间采用service地址（无论内部怎么漂移伸缩，对外地址不变），对于公网上的调用，采用宿主机端口映射出去是个可选方式，当然要结合底层硬件基础设施本身的外网能力，比如阿里还有EIP之类

微服务的伸缩与漂移，需要与监控能力结合，监控结果判断则运用的是万年不变公式：

Result = function1*weight1 + function2*weight2 + …… + functionN*weightN

以漂移为例子，漂移有很多触发器，有因为故障的，有基于优化考虑的，比如像优化漂移这种，就要求定义很多维度，包括资源均衡维度、宿主机特性维度、标签配置变更维度等，需结合多维打分对微服务进行合理调度。

那对于伸缩漂移所依赖的能力上，着重考虑下述两点：

1.                  存储能力，存储可从服务状态特征考虑，一般来说，有状态服务采用共享存储，无状态服务采用非共享或者不适用存储。

2.                  监控能力，点线面结合的监控，需注意对Metrics的正确使用，以及全局流水号等规范约束。

微服务的升级与回退：

1.                  发布要原子化，可编排，每个企业在流程上都会有所区别，只有在完全原子化的情况下，才能保证平台的快速实施

2.                  标签设计，让每个动作、每个状态、每个资源都可以标识；标签设计不仅仅用于部署，我觉得在任何产品中都有借鉴意义

3.                  状态设计，部署是原子化的操作，而内部的状态设计同样重要，比如可结合状态做挂起、唤醒等诸多操作

4.                  版本规范，这个不仅仅是版本号的规范，还包括版本升级规范、配置规范等，不过微服务架构下，建议全量升级与回退

5.                  路由能力，微服务这种快速迭代发布，伴随试错试对，快速变更，灰度等，对流量的出入动态性要求很高

而对于我们来说，使用了rollingupdate机制来进行升级和回退（包括灰度），大家可参考Kubernetes的机制，一种基于标签和Replication的实现方法。对于升级回退、灰度中，最复杂的莫过于数据库以及前端负载的处理问题：

1.                  数据库简单的做法就是类似传统行业，尤其像银行等，只增不减的方式

2.                  前端负载问题要结合业务来实现，很多企业会在Apigateway中考虑，当然不同行业稍有区别，比如在电力行业，IBM给规划的API基线也有这个能力

微服务的熔断与降级，当然熔断与降级并不是一个概念，只是很多时候会一起实现了：

·                     熔断是指上游服务在调用下游服务时，因下游服务的种种问题，对调用链智能处理的手段

·                     降级是指整体资源瓶颈时，一般业务暂停（优先保证核心业务）的一种处理手段

举例：熔断器实现方式，设计参考了一般都使用的三态设计，默认关闭态，调用出错率到一定程度半开，半开时，允许一部分流量继续调用下游微服务，如果一定时间还是出错（这个时间可结合MTTR设置），就将熔断器置为全开态，同样设置一定的时间后再尝试调用；

现在在熔断和降级这块实现的比较好的包括netflix的Hystrix，还有motan，大家都可尝试，我们Hystrix测试过，目前使用了motan，仅从能力上对比，Hystrix无疑更强大。前段时间乐视受攻击，差不多每秒200G流量，最终能撑下来据说主要功劳和这个有关系。

微服务的注册与发现，解决微服务之间的调用、以及一定的客户端和服务端集群的问题。采用etcd作为分布式注册中心，在服务启动和停止时实现注册和注销，运行过程中，会定时同步服务的元信息（比如流量、健康性等），以便实现智能路由。

接着，我们来看看在DevOps实践中的一些关键点：

四要素的提法和友商大同小异，包括组织、流程、技术、文化，下图会将四要素进行更细粒度的要素分解。

组织：包括全栈团队、自治团队等

流程：包括开发、测试、集成、交付、度量等

技术：包括监控、ChatOps等

文化：包括协作、学习等

实现企业级DevOps，有很多方式和着手点，比如最常用的就是从持续发布开始。而我们更聚焦企业的全生命周期，所以在目前版本中（与上图有少许不对应），实现了基于微服务架构的以下15个DevOps领域系统：

1.                  IAM：身份识别与访问管理，通过OAuth能力，一次登录，全网通行

2.                  SPM：软件产品管理，DevOps平台的核心管理对象：产品。以产品维度为入口，管理包括产品的多版本，每个版本拥有多个组件，组件之间、组件与第三方产品之间的依赖关系等

3.                  SCM：软件配置管理，主要是应用配置的管理，在编译打包时通过autoconfig技术，注入到最终部署包

4.                  SRM：软件资源管理，资源，即上述产品的运行实例，所以持续发布等都是有SRM发起

5.                  SEM：软件环境管理，企业环境千差万别，SEM屏蔽了异构环境的差异性，让上游系统及业务能够松耦合的运行

6.                  QAF：质量保证反馈，这个系统负责收集全生命周期的数据反馈，为后续优化演进提供重要依据

7.                  UMC：统一监控中心，主要收集日志及资源运行信息，通过计算分析，形成相关报表，同时与告警中心对接，风险异常准实时提示

8.                  VCS：版本控制系统，默认集成GIT

9.                  CI：持续集成系统，默认集成Jenkins

10.             BPR：二进制仓库

11.             DPR：可部署包（镜像）仓库

12.             PM：项目管理系统，可集成redmine或wiki，目前平台是自己实现的

13.             IM：团队间即时通讯系统

14.             TM：租户管理系统

15.             MKT：云市场，平台最终期望作为中间平台，通过市场打通内容提供者与最终用户

这里对一些DevOps的关键系统协作方式做了一定描述，就不赘述了。

最终这个平台同时支撑了公有云与私有云两条线（8月发布第二版），其中公有云目前运行于阿里云上，使用了阿里云的ECS、VPC、EIP等很少的服务种类；而私有云，目前也在一些企业开始试点。

当然，过程中，尤其是公有云上遇到了不少问题，举两个例子：

1.                  我们采用coreos系统作为宿主系统，阿里云的版本很低，只能自建升级服务器，但升级后网卡默认没有启动，且因为一些service未启动问题，导致无法快照。

2.                  再比如安全组问题，同一安全组的ECS完全不控制的方式，让我们也忙活了很久。

（三）参考与总结

最后分享下我觉得比较好的一些可参考材料，并对分享做下总结：

这个不确定最初是不是Gartner提出的，旨在给DevOps从运营效率、服务、组织、客户价值、业绩维度评估，让企业发现其需要改进的一些点。

平台品质属性，很多时候翻译成质量属性，一种属性分类的方法是把在运行时可识别的特性与那些不可识别的特性区分开），另一种方法是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开，和CAP类似，这些特性有些可叠加，有些则会相互制约，在产品设计时需清楚哪些是您最迫切的。

Heroku的12Factor，这些因素为系统的CloudNative目标考虑，让云上云下得到同样的体验，这12因素不能简单的字面理解，要结合您现在的实际运行来看，则会发现其独到的地方，也不要想一蹴而就，只要时刻有这么根弦，在很多选择前面看看这12因素是否有类似的可参考，比如当时我们纠结了很久的，VCS是否使用TBD模式，其实这里面都可以找到相关答案。

谷歌的Borg，作为谷歌内部的管理调度核心，支撑着谷歌上万台机器及业务的运行，这个虽然是不开源的，但其设计思路和架构是很容易被找到学习的。参考这个的原因是谷歌本身内部就是容器与微服务架构的生产运用，是一个真正大规模的实践参考。

Q&A

问：DevOps对多服务之间的依赖关系有什么好的解决办法吗？

顾伟：我们的概念模型里是产品包含组件，组件依赖第三方产品的关系。在我看来依赖关系分两种，一种是分布式的依赖，比如依赖数据库；一种是二方库或三方库的依赖，嵌入使用。您的情况如果是库存交叉，那为何不把库存服务独立化，我记得有一本书上就是拿您说的库存举例子的。如果现在无法独立服务化，那你的问题就变成数据一致性的问题，这个又有几种处理模式，比如TCC模式，貌似在《微服务设计》这本书中有详细的介绍。

问：对于遗留的业务系统如何落地？

顾伟：对于遗留系统，不建议不管三七二十一就往微服务拆，微服务架构里从来没说不允许双模运行，比如Cloud Foundry的servicebroker，或者企业的ESB这些都可对遗留系统通过集成方式整合。

问：DevOps的基础是环境，如何支持传统IT下和新上私有云公有云中的DevOps？

顾伟：这点我们正好刚做到了，核心是异构环境的管理，我上面提到过一个sem领域系统就是来做这件事情的，难点在于网络和介质共享，网络可采用VPC方式。我们现在是把家里的传统环境与阿里云环境统一管理的，在某些客户那边开发测试在公有云，上线在私有云的也有。

问：对各种私有云和公有云的支持是怎么做到的？比如要把应用跑到阿里云、青云、AWS、Azure、内网OpenStack。

顾伟：DevOps不是一蹴而就的，也不可能让传统IT系统的过程完全云化，这是个循序的过程，建议从自助和自动入手。我们其实也没有做到各种私有云和公有云，这个是个集成的活，我们现在只做到了OpenStack、VMware、阿里云，因为我们是容器支撑，相对来说跟底层耦合度反而低。比如阿里云，只要有一定的资源池管理能力，能够支撑容器计算节点的伸缩和SLA就可以集成了，并不复杂。AWS也试过，如果AWS国内有数据中心，其实反而简单了，可以用上它的逻辑网，DNS等很多服务，这个在用阿里云时反而要自己搭。

问：涉及多个云后，用容器就会产生多个资源池，这些资源池本身以及容器云是如何管理的？

（顾伟原创）

作者围绕其这些年在OpenStack、Kubernetes、Microservice、DevOps、Cloud Foundry、ELK等云计算相关领域及技术的实践，从微服务和DevOps两方面着手，旨在为两者的落地提供一个快速可行路径。针对这“说说还可以，一深入讨论就吵架”的热点概念，详解了在产品研发过程中的思考与实践，通过多维度的架构与技术剖析，与大家深入沟通云计算的企业级落地思路。本文是从作者这些年的经历与实践出发的总结，也欢迎感兴趣的同学参与交流、保持沟通与学习。（备注：作者微信二维码详见文末）。

（一）服务与DevOps的认识

现在见客户就会聊微服务、聊DevOps、聊容器，但这种热点概念，真的是“简单聊聊可以，一深入就吵架”，比如以前谁问我传统应用该怎么拆分，我还会说一堆，现在基本上对于这种开放型问题都不敢回答了，怕“没朋友”。

我简单说说我对微服务和DevOps的认知吧：

第一个就不说了，第二个垂直架构，典型的比如SSH框架，帮大家考虑了模块化、MVC等，但并没有考虑服务化。

第三个是分布式架构，以SOA为代表的这类技术已经热了很多年，也很成熟，也是目前很多企业架构的主体支撑。

而第四个以微服务架构为支撑的技术虽然在一些先进企业或互联网公司已经运用，但从生态上来看，还有很长一段时间要走，其更强调在DDD下的业务服务自治性及原子性。

“DevOps”通常指的是新兴的专业化运动，这种运动提倡开发和IT运维之间的高度协同，从而在完成高频率部署的同时，提高生产环境的可靠性、稳定性、弹性和安全性。

其概念也特别多，简单浏览下就可以了：DevOps运动的起源通常被放在2009年前后，伴随着许多运动的相辅相成和相互促进——效率研讨会运动，特别是由JohnAllspaw和Paul Hammond展示的开创性的“一天10次部署”，基础设施即代码”运动(Mark Burgess和LukeKanies)，“敏捷基础设施运动”(Andrew Shafer)，“敏捷系系统管理(PatrickDeBois)，“精益创业”运动（EricRies），JezHumble的持续集成和发布运动，以及Amazon的“平台即服务运动”等这些运动的相辅相成和相互促进而发展起来的。

那云计算、微服务、容器这些概念或能力之间到底是什么关系呢？其实这个主要看大家的方向了，结合我所面临的客户以及IT现状，我的理解是这样的：

1.                  云基础平台作为底层支撑，既可以是Docker、Unikernel这样的容器技术，也可以像vmware或OpenStack这样以VM为管理单元的方式，旨在为上层提供有SLA能力的资源池管理与调度；

2.                  DevOps作为一层可选平台，以流程自动化、工具自动化为主要手段，通过长期的积累与优化，为最终业务交付提供更敏捷、更数字化的能力；

3.                  历史系统与微服务在企业会长时间并存（BiModal），不要试图一步到位，我所经历的企业客户中，都是从部分外围应用开始试点，甚至是先拆应用、再拆数据这样循序渐进的。

（二）平台级的实践与支撑

先和大家说说我们的平台具体在做什么：

这个定位（非市场定位）讲起来比较拗口，“用微服务架构，做云计算DevOps平台，支撑上层微服务的全生命周期管理”。

这里有个鸡生蛋、蛋生鸡的问题，那我们还是通过制定微服务的规范以及一部分配套工具，基于这些开发了第一版DevOps云平台，将其作为后续版本的生产线使用。过程中对康威定律又有了进一步认识，尤其是运用在异地协作和技术选型上，团队能力、异地松耦合是必须考虑的维度。

先将平台用到的一些技术栈列出来：

图中标红的是目前我们已使用的，相信大家不难看出来：

1.                  我们主要是走的容器云这条线（当然传统的也是支持的），以Kubernetes为容器管理与调度的框架，结合Flannel网络、Ceph存储形成底层基础支撑

2.                  微服务方面使用SpringBoot作为载体，引入了Netflix的部分框架支撑微服务调用、配置

3.                  在全生命周期中，还支持了文档、Mock、自动化测试的能力，以便微服务架构下的快速交付

4.                  在监控方面采用Journald采集，Fluentd作为server、同时通过索引及时序库支撑数据分析及展现

这里有三个想法与大家共勉：

1.                  架构师的角色转变，从原来的技术货架的搭建（加法）到现在海量技术中选择最合适的（减法），对能力的要求更高

2.                  个人全栈已经不再多见，而团队全栈却越来越重要，学习型组织将是未来衡量团队能力的一大标准

3.                  框架能力的阳性与阴性，同样是结合现在海量技术来看，测试是必不可少的，但业务场景的多变往往会造成数据的片面性，比如Flannel的UDP和Vxlan模式（就像体育赛场上一样，阳性不好，但伪阴性就更糟糕了）

接着分别从微服务和DevOps方面来看看我们的一些关键设计和想法，先说说微服务架构：

当然微服务架构中重要的不仅仅是上述的5个能力：

1.                  服务的隔离与互通

2.                  伸缩与漂移

3.                  升级与回退

4.                  熔断与降级

5.                  服务注册与发现

上图亦可理解为是核心概念模型，面向的问题是这样的：

·                     有些企业会考虑生产上VM，开发测试上容器；

·                     有些企业需要开发测试预发上线四套环境，有些只要两套：

·                     有些企业环境间要求完全隔离，有些只要逻辑隔离；

·                     有些企业要求对接下层资源池，有些则完全没有资源池的概念；

·                     …...

那概念模型上我们怎么办？上图的核心是业务运行及namespace的设计，下层无论资源有没有池化，都需要加一层Namespace的管理，这个管理有很多目标，比如隔离，再比如池化。

然后紧接着是pod，这个概念参考了Kubernetes，在微服务运行时，一直强调一个业务的独立性，比如一个业务，其应用及数据库是绑定的，且与其他业务隔离。那我们认为这种就是一个pod（豌豆荚），体现的是一个独立业务（微服务）。

一个pod无论内部如何，一般是跑在一台宿主机的，业务内部尽量本地调用，pod可以包括多个进程，也可以包含多个容器，也就是上图的pod与process的关系。

从可靠性及性能考虑，pod必须是集群的，所以一个pod可以有多个副本，也就是上图的pod与replication的关系。

最终业务要能对外提供能力，类似一个集群对外的统一发布地址，也就是上图的service的概念，service是外部的访问入口，并拥有一定的负载均衡能力。

下图是运行时的调用过程示意：

互通要求的是“可达、快速可达、安全并快速可达”。一个微服务内部可采用本地方式，而微服务之间采用service地址（无论内部怎么漂移伸缩，对外地址不变），对于公网上的调用，采用宿主机端口映射出去是个可选方式，当然要结合底层硬件基础设施本身的外网能力，比如阿里还有EIP之类

微服务的伸缩与漂移，需要与监控能力结合，监控结果判断则运用的是万年不变公式：

Result = function1*weight1 + function2*weight2 + …… + functionN*weightN

以漂移为例子，漂移有很多触发器，有因为故障的，有基于优化考虑的，比如像优化漂移这种，就要求定义很多维度，包括资源均衡维度、宿主机特性维度、标签配置变更维度等，需结合多维打分对微服务进行合理调度。

那对于伸缩漂移所依赖的能力上，着重考虑下述两点：

1.                  存储能力，存储可从服务状态特征考虑，一般来说，有状态服务采用共享存储，无状态服务采用非共享或者不适用存储。

2.                  监控能力，点线面结合的监控，需注意对Metrics的正确使用，以及全局流水号等规范约束。

微服务的升级与回退：

1.                  发布要原子化，可编排，每个企业在流程上都会有所区别，只有在完全原子化的情况下，才能保证平台的快速实施

2.                  标签设计，让每个动作、每个状态、每个资源都可以标识；标签设计不仅仅用于部署，我觉得在任何产品中都有借鉴意义

3.                  状态设计，部署是原子化的操作，而内部的状态设计同样重要，比如可结合状态做挂起、唤醒等诸多操作

4.                  版本规范，这个不仅仅是版本号的规范，还包括版本升级规范、配置规范等，不过微服务架构下，建议全量升级与回退

5.                  路由能力，微服务这种快速迭代发布，伴随试错试对，快速变更，灰度等，对流量的出入动态性要求很高

而对于我们来说，使用了rollingupdate机制来进行升级和回退（包括灰度），大家可参考Kubernetes的机制，一种基于标签和Replication的实现方法。对于升级回退、灰度中，最复杂的莫过于数据库以及前端负载的处理问题：

1.                  数据库简单的做法就是类似传统行业，尤其像银行等，只增不减的方式

2.                  前端负载问题要结合业务来实现，很多企业会在Apigateway中考虑，当然不同行业稍有区别，比如在电力行业，IBM给规划的API基线也有这个能力

微服务的熔断与降级，当然熔断与降级并不是一个概念，只是很多时候会一起实现了：

·                     熔断是指上游服务在调用下游服务时，因下游服务的种种问题，对调用链智能处理的手段

·                     降级是指整体资源瓶颈时，一般业务暂停（优先保证核心业务）的一种处理手段

举例：熔断器实现方式，设计参考了一般都使用的三态设计，默认关闭态，调用出错率到一定程度半开，半开时，允许一部分流量继续调用下游微服务，如果一定时间还是出错（这个时间可结合MTTR设置），就将熔断器置为全开态，同样设置一定的时间后再尝试调用；

现在在熔断和降级这块实现的比较好的包括netflix的Hystrix，还有motan，大家都可尝试，我们Hystrix测试过，目前使用了motan，仅从能力上对比，Hystrix无疑更强大。前段时间乐视受攻击，差不多每秒200G流量，最终能撑下来据说主要功劳和这个有关系。

微服务的注册与发现，解决微服务之间的调用、以及一定的客户端和服务端集群的问题。采用etcd作为分布式注册中心，在服务启动和停止时实现注册和注销，运行过程中，会定时同步服务的元信息（比如流量、健康性等），以便实现智能路由。

接着，我们来看看在DevOps实践中的一些关键点：

四要素的提法和友商大同小异，包括组织、流程、技术、文化，下图会将四要素进行更细粒度的要素分解。

组织：包括全栈团队、自治团队等

流程：包括开发、测试、集成、交付、度量等

技术：包括监控、ChatOps等

文化：包括协作、学习等

实现企业级DevOps，有很多方式和着手点，比如最常用的就是从持续发布开始。而我们更聚焦企业的全生命周期，所以在目前版本中（与上图有少许不对应），实现了基于微服务架构的以下15个DevOps领域系统：

1.                  IAM：身份识别与访问管理，通过OAuth能力，一次登录，全网通行

2.                  SPM：软件产品管理，DevOps平台的核心管理对象：产品。以产品维度为入口，管理包括产品的多版本，每个版本拥有多个组件，组件之间、组件与第三方产品之间的依赖关系等

3.                  SCM：软件配置管理，主要是应用配置的管理，在编译打包时通过autoconfig技术，注入到最终部署包

4.                  SRM：软件资源管理，资源，即上述产品的运行实例，所以持续发布等都是有SRM发起

5.                  SEM：软件环境管理，企业环境千差万别，SEM屏蔽了异构环境的差异性，让上游系统及业务能够松耦合的运行

6.                  QAF：质量保证反馈，这个系统负责收集全生命周期的数据反馈，为后续优化演进提供重要依据

7.                  UMC：统一监控中心，主要收集日志及资源运行信息，通过计算分析，形成相关报表，同时与告警中心对接，风险异常准实时提示

8.                  VCS：版本控制系统，默认集成GIT

9.                  CI：持续集成系统，默认集成Jenkins

10.             BPR：二进制仓库

11.             DPR：可部署包（镜像）仓库

12.             PM：项目管理系统，可集成redmine或wiki，目前平台是自己实现的

13.             IM：团队间即时通讯系统

14.             TM：租户管理系统

15.             MKT：云市场，平台最终期望作为中间平台，通过市场打通内容提供者与最终用户

这里对一些DevOps的关键系统协作方式做了一定描述，就不赘述了。

最终这个平台同时支撑了公有云与私有云两条线（8月发布第二版），其中公有云目前运行于阿里云上，使用了阿里云的ECS、VPC、EIP等很少的服务种类；而私有云，目前也在一些企业开始试点。

当然，过程中，尤其是公有云上遇到了不少问题，举两个例子：

1.                  我们采用coreos系统作为宿主系统，阿里云的版本很低，只能自建升级服务器，但升级后网卡默认没有启动，且因为一些service未启动问题，导致无法快照。

2.                  再比如安全组问题，同一安全组的ECS完全不控制的方式，让我们也忙活了很久。

（三）参考与总结

最后分享下我觉得比较好的一些可参考材料，并对分享做下总结：

这个不确定最初是不是Gartner提出的，旨在给DevOps从运营效率、服务、组织、客户价值、业绩维度评估，让企业发现其需要改进的一些点。

平台品质属性，很多时候翻译成质量属性，一种属性分类的方法是把在运行时可识别的特性与那些不可识别的特性区分开），另一种方法是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开，和CAP类似，这些特性有些可叠加，有些则会相互制约，在产品设计时需清楚哪些是您最迫切的。

Heroku的12Factor，这些因素为系统的CloudNative目标考虑，让云上云下得到同样的体验，这12因素不能简单的字面理解，要结合您现在的实际运行来看，则会发现其独到的地方，也不要想一蹴而就，只要时刻有这么根弦，在很多选择前面看看这12因素是否有类似的可参考，比如当时我们纠结了很久的，VCS是否使用TBD模式，其实这里面都可以找到相关答案。

谷歌的Borg，作为谷歌内部的管理调度核心，支撑着谷歌上万台机器及业务的运行，这个虽然是不开源的，但其设计思路和架构是很容易被找到学习的。参考这个的原因是谷歌本身内部就是容器与微服务架构的生产运用，是一个真正大规模的实践参考。

Q&A

问：DevOps对多服务之间的依赖关系有什么好的解决办法吗？

顾伟：我们的概念模型里是产品包含组件，组件依赖第三方产品的关系。在我看来依赖关系分两种，一种是分布式的依赖，比如依赖数据库；一种是二方库或三方库的依赖，嵌入使用。您的情况如果是库存交叉，那为何不把库存服务独立化，我记得有一本书上就是拿您说的库存举例子的。如果现在无法独立服务化，那你的问题就变成数据一致性的问题，这个又有几种处理模式，比如TCC模式，貌似在《微服务设计》这本书中有详细的介绍。

问：对于遗留的业务系统如何落地？

顾伟：对于遗留系统，不建议不管三七二十一就往微服务拆，微服务架构里从来没说不允许双模运行，比如Cloud Foundry的servicebroker，或者企业的ESB这些都可对遗留系统通过集成方式整合。

问：DevOps的基础是环境，如何支持传统IT下和新上私有云公有云中的DevOps？

顾伟：这点我们正好刚做到了，核心是异构环境的管理，我上面提到过一个sem领域系统就是来做这件事情的，难点在于网络和介质共享，网络可采用VPC方式。我们现在是把家里的传统环境与阿里云环境统一管理的，在某些客户那边开发测试在公有云，上线在私有云的也有。

问：对各种私有云和公有云的支持是怎么做到的？比如要把应用跑到阿里云、青云、AWS、Azure、内网OpenStack。

顾伟：DevOps不是一蹴而就的，也不可能让传统IT系统的过程完全云化，这是个循序的过程，建议从自助和自动入手。我们其实也没有做到各种私有云和公有云，这个是个集成的活，我们现在只做到了OpenStack、VMware、阿里云，因为我们是容器支撑，相对来说跟底层耦合度反而低。比如阿里云，只要有一定的资源池管理能力，能够支撑容器计算节点的伸缩和SLA就可以集成了，并不复杂。AWS也试过，如果AWS国内有数据中心，其实反而简单了，可以用上它的逻辑网，DNS等很多服务，这个在用阿里云时反而要自己搭。

问：涉及多个云后，用容器就会产生多个资源池，这些资源池本身以及容器云是如何管理的？

（顾伟原创）