导读：本次分享围绕作者这些年在OpenStack、Kubernetes、Microservice、DevOps、Cloudfoundry、ELK等云计算相关领域及技术的实践，从微服务和DevOps两方面着手，旨在为两者的落地提供一个快速可行路径。针对这“说说还可以，一深入讨论就吵架”的热点概念，详解了在产品研发过程中的思考与实践，通过多维度的架构与技术剖析，与大家深入沟通云计算的企业级落地思路。

本文不局限于微服务与DevOps，更多的从自己这些年的经历与实践来和大家交流，更希望本次分享之后能和各位长期保持沟通与学习。

今天的分享包括以下四部分：

1.我经历的云计算历程：简单介绍下自己参与的一些产品研发，然后从现在市场格局的角度，提出一些自己作为云计算产品线负责人的想法；

2.微服务与DevOps的认识：围绕今天的主题，从微服务与DevOps角度，阐述自己的理解；

3.平台级的实践与支撑：基于当前正在研发的“基于微服务架构的DevOps平台”，详解我们的设计与技术，当然也会有些坑里面会提到；

4.参考与总结：整个过程中我们也参考了很多优秀的架构与理念，希望对大家也有用，最后给今天的分享做个总结；

我经历的云计算历程

严格来算，我是09年开始做和云计算有关的事情的，中间经历了很多方向、技术的变更，对个人确实有好处（接触更多的人和事嘛），但对于产品线来说，这往往是很不明智的：

09年：如果放到现在大家会叫它为“传统的PaaS平台”，我们做了一款“云应用交付平台”，平台面向于运营商，帮助其更快速的部署轻量化的应用及服务，并提供了一定的快速伸缩能力，平台没有用到现在大家熟悉的技术栈，说实话，就是个土生土长的有点土的家伙；

11年：正值OpenStack与CloudStack兴起，我们也看到了云计算的“美好前景”，从IaaS层着手，旨在从所谓的“千亿”市场分一杯羹，“理想很美好，现实很残酷”；

13年：混合云模式逐步被接受，大家是否记得前段时间刚刚正式下线的ACE平台，当时我们就参与了这款平台的企业级落地，虽有成功案例，但混合云目前的形式，大家都是清楚的；

15年：我们走到了现在的阶段，以容器为默认承载，微服务架构为支撑，打造企业级DevOps数字化平台，事实证明这个13年就想到过的点子是很成功的，成功在于两面：市场上的客户反馈（包括收入）和内部的能力驱动（团队使能）。

那我们再来看看现在的云计算格局：

我不太喜欢用标准的IaaS、PaaS、SaaS来区分，我认为这个界限越来越模糊（比如我们甭管好不好，三者都做），我更倾向于UCOBP的模式来看待领域：

1.就目前来说在运营商和软硬件提供商来看，市场趋于稳定，大家都还把住了自己的核心优势（体量、门槛…）

2.但从集成商和应用或者服务提供商来看，这些市场还是面临着竞争，比如现在的很多创业公司，都是瞄准这两块开始的

我觉得像现在的云计算、大数据、移动互联、物联网、人工智能等大领域（其实我觉得泛领域更合适），进去很容易，想做好（至少赚到钱，借马云名言：“能赚到钱的不一定有价值，对社会有价值一定能赚到钱”）是要有几个前提的：

1.定位要明确，你在这些泛领域中有没有找到市场地位，不求找到的都是蓝海，但不能使劲往红海挤；

2.方式要合理，我们一直遵循一个很简单的方法，我们自己叫“厚+薄”，这个面向企业市场很有用。所谓“厚”是说企业流程都是复杂的，无论用什么，需要基于企业级流程串接；所谓“薄”是说现在开源技术多如满天星，如何去其糟粕，取其精华，是我们要总结的；

3.基因很重要，下一个红帽也许永远不会再出现了，不仅仅IT市场，大家的朋友如果做生意一样能感受到，以前只要愿意努力去做，加上一点点聪明，基本上不会失败；现在如果你要去拓新一个完全未知或不相干领域，基本上会有两条死路，做不起来或者做起来点儿被巨头给cut了。

微服务与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.服务注册与发现

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

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

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

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

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

5. ...

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

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

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

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

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

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

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

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

1. Result = function1*weight1 + function2*weight2 + …… + functionN*weightN。

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

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

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

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

微服务的升级与回退：

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

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

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

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

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

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

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

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

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

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

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

举例：熔断器实现方式，设计参考了一般都使用的三态设计，默认关闭态，调用出错率到一定程度半开，半开时，允许一部分流量继续调用下游微服务，如果一定时间还是出错（这个时间可结合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，作为谷歌内部的管理调度核心，支撑着谷歌上万台机器及业务的运行，这个虽然是不开源的，但其设计思路和架构是很容易被找到学习的。参考这个的原因是谷歌本身内部就是容器与微服务架构的生产运用，是一个真正大规模的实践参考。

回顾一下今天的分享：

1.先谈了谈我的云计算历程以及对今日主题的认识；

2.接着从实践角度分享了我们在微服务和DevOps上的处理，包括5能力和4要素；

3. 最后给了一些我们过程中参考的设计，希望对各位有用。