CloudNative介绍
背景
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：如何达到分享⽼师这种技术深度、⼴度、理念？
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议