一篇文章带你了解Cloud Native

转自：https://blog.csdn.net/u011537073/article/details/72360966?locationNum=8&fps=1&utm_campaign=studygolang.com&utm_medium=studygolang.com&utm_source=studygolang.com

背景

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

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：反腐层，这层完成对老系统的桥接，并阻止老系统的腐烂蔓延。它包含三部分：

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

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

4、微服务核心技术点

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

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：其他节点同步更新

2）、服务注册和发现

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

备注：Consumer和Producer之间一般还有个LB

3）、路由和LB

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. 把大的并行处理工作，由多个线程池来负荷分担

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）的规范

评估参考下面表格：