一篇文章带你了解Cloud Native

背景

Cloud Native表面看起来比较容易理解，可是细思好像又有些模糊不清：Cloud Native和Cloud关系是啥？它用来解决什么问题？它是一个新技术仍是一个新的方法？什么样的APP符合“云原生”的呢？等等。下面将会一一解读。 

Cloud Native介绍

Cloud Native是Matt Stine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。 

能够说，Cloud Native即包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。Cloud Native也能够说是一系列Cloud技术、企业管理方法的集合。 

Cloud Native的价值

企业采用基于Cloud Native的技术和管理方法，能够更好的把业务迁移到云平台，从而享受云的高效和按需资源能力。 

Cloud Native和传统Cloud的关系

Cloud Native的技术部分是建筑在传统Cloud的三层（IaaS、PaaS、SaaS）概念之上的： 

• 敏捷基础设施对应IaaS部分。
• 微服务则能够对应PaaS和SaaS部分。

固然，Cloud Native比传统Cloud 多了一些企业管理方法。 

备注：Cloud Native从技术上更强调敏捷基础设施和微服务的概念，这并不意味着它是抛开IaaS、PaaS、SaaS而另起炉灶的。

Cloud Native的五个层面：

（1） 康威定律：业务云化推行，从某种意义上讲也是一种变革。既然是变革，必然会涉及组织的各个层面，开发、质量、运维等等都会涉及。康威定律则准确的描述了系统架构和组织的关系：组织决定系统架构！ 

一个云系统最终长成什么样子，则彻底是企业的组织结构决定的，是组织内部、组织之间的沟通结构。 

若是要想获得一个合理的Cloud架构，仅从技术入手是不够的，还须要从组织架构入手，才真正有效。 

（2） DevOps：（英文Development和Operations的组合）是一组过程、方法与系统的统称，用 于促进开发（应用程序/软件工程）、运维和质量保障（QA）部门之间的沟通、协做与整合。它的出现是因为软件行业日益清晰地认识到：为了按时交付软件产品 和服务，开发和运维必须紧密合做。 

（3） 持续交付（Continuous Delivery）：是一系列的开发实践方法，用来确保让代码可以快 速、安全的部署到产品环境中，它经过将每一次改动都提交到一个模拟产品环境中，使用严格的自动化测试，确保业务应用和服务能符合预期。由于使用彻底的自动 化过程来把每一个变动自动的提交到测试环境中，因此当业务开发完成时，你有信心只须要按一次按钮就能将应用安全的部署到产品环境中。持续交付能够采 用：CI（持续集成）、代码检查、UT（单元测试），持续部署等方式，打通开发、测试、生产的各个环节，持续的增量的交付产品。 

（4） 微服务（MicroServices）：微服务首先是一个服务，其次该服务的颗粒比较小。微服务能够采用Docker、LXC等技术手段实现。 

（5） 敏捷基础设施（Agile Infrastructure）：提供弹性、按需的计算、存储、网络资源能力。能够经过Openstack、KVM、Ceph、OVS等技术手段实现。 

Cloud Native兴起的背后诉求

• 更快的上线速度
• 细致的故障探测和发现
• 故障时能自动隔离
• 故障时可以自动恢复
• 方便的水平扩容

 

Cloud Native能够解决上面的诉求：

• 持续交付、DevOps、微服务解决-->更快的上线速度
• 微服务解决-->细致的故障探测和发现
• 微服务解决-->故障时能自动隔离
• 敏捷基础设施、微服务解决-->故障时可以自动恢复
• 敏捷基础设施、微服务解决-->方便的水平扩容

 

如何推行Cloud Native

推行Cloud Native能够从以下几方面入手： 

• 组织变革：根据康威定律，若是要达到比较理想的云化效果，必须进行组织变革。一个合理的组织架构，将会极大提升云化的推行。相信不少公司，在决定搞云计算后，都大大小小进行了部门合并和组织结构调整。这块水比较深，相信不少人有变革的切肤之痛。
• 推行DevOps文化：在公司层面推行DevOps文化，倡导开放、合做的组织文化，打破“部门墙”。
• 推行持续交付：联合开发、质量、运维各个环节，打通代码提交、代码检查、UT、开发环境部署、staging环境部署、线上环境部署等流水线。
• 建设敏捷基础设施：这部分是整个Cloud Native的根基。这部分能够采纳的技术很是多，开源的、商用的都比较多。
• 采用微服务架构：微服务架构是Cloud Native的一个核心要素。微服务包含几方面的内容： （1）有支撑微服务的平台。
  （2）有符合微服务平台规范的APP。
  （3）如何引入微服务。
  （4）微服务核心技术点。

 

微服务的4个方面

（1）有支撑微服务的平台

支撑微服务的可选技术框架比较多，每一个公司均可以根据自身状况选择合适的技术框架。好比： 

• Kubernetes
• Mesos+Docker
• OpenShift V3
• Machine + Swarm + Compose
• OpenStack + Docker
• Cloud Foundry Lattice 其余技术等等

这方面的资料很是多，再也不细讲。 

（2）有符合微服务平台规范的APP

APP要符合12因子（Twelve-Factor）的规范： 

• 基准代码（Codebase）：代码必须归入配置库统一管理。
• 依赖（Dependencies）：显式的声明对其余服务的依赖，好比经过Maven、Bundler、NPM等。
• 配置（Config）：对于不一样环境（开发/staging/生产等）的参数配置，是经过环境变量的方式进行注入。
• 后台服务（Backing services）：对于DB、缓存等后台服务，是做为附加资源，能够独立的Bind/Unbind。
• 编译/发布/运行（Build、Release、Run）：Build、Release、Run这三个阶段要清晰的定义和分开。
• 无状态进程（Processes）：App的进程是无状态的，任何状态信息都存储到Backing services（DB，缓存等）。
• 端口绑定（Port binding）：App是自包含的，全部对外服务经过Port Binding暴露，好比经过Http。
• 并发（Concurrency）：App能够水平的Scaling。
• 快速启动终止（Disposability）：App进程能够被安全的、快速的关闭和重启。
• 环境一致性（Dev/prod parity）：尽量的保持开发、staging、线上环境的一致性。
• 日志（Logs）：把日志做为事件流，无论理日志文件，经过一个集中的服务，由执行环境去收集、聚合、索引、分析日志事件。

 

（3）如何引入微服务

直接对原有系统进行微服务改造，是比较困难的，几乎是不现实的。比较合理的方法是新系统采用微服务开发，对老系统进行服务封装，系统架构以下所示： 

Monolith系统：对应企业老的系统。 

The Anti-Corruption Layer：反腐层，这层完成对老系统的桥接，并阻止老系统的腐烂蔓延。它包含三部分： 

1. Facade：简化对老系统接口的对接。
2. Adapter：Request，Response 请求协议适配
3. Translator：领域模型适配，转换微服务模型和老系统模型。

新系统（微服务）：新系统开发采用微服务架构。 

（4）微服务核心技术点

主要包含以下几个方面：版本控制的分布式配置中心、服务注册和发现、路由和LB、容错、API网关/边缘服务。 

（4.1）版本控制的分布式配置中心

支持配置信息版本化控制，可审计，安全，配置更新不须要重启，分布式。这部分能够参考Spring Cloud Config Server、Spring Cloud Bus。 

1：用户提交配置更新 
2：配置server更新 
3：对APP A发起Refresh更新配置操做 
4a：发送消息到Bus 
4b：Pull 更新的配置 
5a：APP C接收消息 
5b：Pull更新的配置 
6：其余节点同步更新 

（4.2）服务注册和发现

这个是传统的服务注册和发现架构图。服务注册方式，常见的包括DNS，基于ZooKeeper的服务注册方案等等。 

备注：Consumer和Producer之间通常还有个LB。

（4.3）路由和LB

 

（4.4）容错

介绍两种模式： 
（A）电路熔断器（Circuit Breaker）： 该模式的原理相似于电路熔断器，若是电路发生短路，熔断器可以主动熔断电路，以免灾难性损失 

 

1. 正常状态下，电路处于关闭状态（Closed），调用是直接传递给依赖服务的；
2. 若是调用出错，则进入失败计数状态；
3. 失败计数达到必定阈值后，进入熔断状态（Open），这时的调用老是返回失败；
4. 累计一段时间之后，保护器会尝试进入半熔断状态（Half-Open）；
5. 处于Harf-Open状态时，调用先被传递给依赖的服务，若是成功，则重置电路状态为“Closed”，不然把电路状态置为“Open”；

（B）舱壁（Bulkheads）：该模式像舱壁同样对资源或失败单元进行隔离，若是一个船舱破了进水，只损失一个船舱，其它船舱能够不受影响 。 

这种模式比较常见的思路为： 

1. 采用微服务是首选，好比Docker。Docker是进程隔离的，单个Docker失效不会影响其余Docker容器。
2. 把大的并行处理工做，由多个线程池来负荷分担。

 

（4.5）API网关/边缘服务

API Gateway： 

1. 对设备侧（PC,Mobile等）提供简化的单一服务接口；
2. 它内部聚合后台几十甚至上百微服务。

 

价值：它的主要做用是简化设备侧开发的复杂度，减小微服务网络调用数量和网络延迟问题。

VIP Cloud Native实践

参考Cloud Native理念，分别介绍VIP实践。 

1. 组织层面：Cloud的推行是由专门的云平台部门来完成的。云平台拉通开发、QA、运维等各个部门， 一块儿推进电商业务的云化。在推行Cloud过程当中，咱们也碰到了大部分公司都面临的“部门墙”问题。所以，目前咱们在尝试“项目制”运做方式：成立一个项 目组，把相关利益责任人拉进来，由PMO推进落实。
2. 持续交付：目前咱们已经开发了CI、CD，正在并联合QA Tool工具部，线上发布系统，打通开发、QA、运维等，造成端到端的持续交付流程。持续交付的流程图以下：
   
3. 敏捷基础设施
   
4. 微服务：目前惟品会部分业务在尝试采用基于Docker的微服务架构，大部分仍是采用SOA服务架 构。一个服务的概念，对应于咱们内部的一个业务域概念，目前有1K多的业务域。随着VIP业务的快速发展，单个业务域的容量也会快速增加。所以，业务域也 在逐步的拆分中，业务域数据也会增加几倍。
5. 12因子（Twelve-Factor）评估：因为是基于SOA架构设计，大部分能够知足12因子（Twelve-Factor）的规范。
   评估参考下面表格：
   

 

Q&A

Q：如何达到分享老师这种技术深度、广度、理念？ 

A：过奖了，谢谢。有几点能够和你们分享一下： 

1. 技术都是慢慢积累过来的，你作的久了，天然知道的就多些，作技术贵在坚持。
2. 多和一些大牛学习和交流很重要，最直接的就是多向你的直接领导请教；
3. 多学习，天天坚持学习；
4. 平台很重要，有个很好的发展平台可让你多学习不少内容。

Q：惟品会属于康威定律中哪类公司，对促进Cloud Native都做了哪些组织结构上的调整？ 

A：为了推行Cloud Native，咱们成立专门的云计算部门。可是为了推行云，咱们须要和周边各个部门打交道。推行IaaS还好说，由于这块基本上是标准化的东东，可是在推 行CI、CD时碰到不少问题。CI、CD是和业务密切相关的，规范的推行，必然会给你们带来额外的工做量。针对这些问题，咱们是联合多个部门一块儿搞，项目 制运做。

Q：在实际使用过程当中，12因子是定性的仍是定量的，如何检测？ 

A：应该是定性和定量结合更为合适。好比代码统一放入Git库，这个是定性。可是代码提交次数，代码圈复杂度大小，CI成功率等就是定量的。

Q：针对移动端的自动化测试，大家是怎么作的？大家的服务发现是如何作的？ 

A：移动端的自动化测试，这块了解有限，暂时没法答复你。服务发现，咱们有两种模式：DNS传统模式，另一个就是基于自研OSP开放平台的服务注册、服务发现模式。

Q：灰度发布采用的什么策略，是AB两个集群轮流替换的方式吗？ 

A：目前是按批次分批发布的，好比50个节点，先升级1个，再升级20，最后升级29个。

Q：自动化测试是怎么作的，尤为是Web应用的自动化测试，采用的什么工具？ 

A：我知道的有Test link。

Q：这些云上的数据库是如何部署的，处理的数据规模有多大，事务吞吐量多少，扩容这块如何实践的？ 

A：DB有专门的部署工具，对于规模和事务吞吐量、扩容问题，这个比较敏感，能够线下专门交流。

Q：请问，惟品会目前云上用的是什么数据库？ 

A：MySQL、MongoDB。

Q：请教一下，后台数据库是如何分离的，好比，是否是先从用户微服务中拿用户列表，在用用户ID去商品微服务中去拿这个用户的商品列表？ 

A：后台DB连接信息通常能够做为环境变量注入App中。

Q：在基础设施上您同时使用了虚拟机和Docker，请问这两种基础设施承载业务也不一样吗？ 

A：虚拟机目前是开发测试环境用。Docker后续会直接用在生产环境，主要是无状态App甚至缓存。其实VM大部分场景均可以使用Docker代替。

Q：在服务注册和发现的图里Consumers应该不会直接链接Producer吧， 通常会经过企业治理esg链接？ 

A：Producer和Consumer之间通常还有个LB。

Q：能把预发布环境理解为集成测试环境吗？ 

A：预发布是上线前的一个环节，连接的DB都是线上真实环境的。集成测试环境，还在预发布环节的前面。

Q：做为环境变量到终端DB安全性如何保证，难道是每一个用户一个DB？ 

A：通常是后台service连接DB的吧，用户是没法接触DB的。

Q：那个动态更新配置的服务是须要启动一个守护进程去更新吗？ 

A：通常来讲，client都会安装一个配置agent，它来负责从配置server pull配置进行更新。

Q：怎么理解版本控制的分布式配置中心，主要是配置的哪些信息？ 

A：好比Nginx配置（端口、vhost等）、tomcat配置、DB连接信息、缓存连接信息等等。

Q：12因子是否过于严格，嘉宾的表格里关于应用无状态也只是部分知足？ 

A：12因子主要针对App的，它不适用于service层面，好比对于db，mc的服务是不适合的。

Q：Gateway实现是使用开源框架（kong、loopback）仍是本身实现？ 

A：既能够本身实现（好比Java、Nginx），也能够采用开源的，好比Zuul。

Q：必要时进行协议转换（好比Http转为AMQP）？ 

A：好比外部是经过http rest请求的，拿到这个请求后，把参数封装，而后以mq的方式发给后台其余服务。

Q：微服务必定是无状态的吗？ 

A：这个不必定的。

Q：能介绍OpenStack 在项目中怎么和Docker等结合使用的吗？ 

A：目前咱们的CI采用Docker，Docker直接跑在VM（VM由OpenStack建立）上。对于OpenStack底层和Docker如何结合，目前还在方案评估中。