Cloud Native和微服务

一、Cloud Native介绍

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

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

二、和Cloud的关系

Cloud Native的技术部分是建筑在传统Cloud的三层（IaaS、PaaS、SaaS）概念之上的：
敏捷基础设施对应IaaS部分。
微服务则可以对应PaaS和SaaS部分。

当然，Cloud Native比传统Cloud 多了一些企业管理方法。 Cloud Native从技术上更强调敏捷基础设施和微服务的概念，这并不意味着它是抛开IaaS、PaaS、SaaS而另起炉灶的。

三、Cloud Native的五个层面

（1） 康威定律：

Conway’s law: Organizations which design systems[…] are constrained to produce designs which are copies of the communication structures of these organizations.（设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。 )

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

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

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

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

（3） 持续交付（Continuous Delivery）：
Continuous Delivery (CD) is the process to build, test, configure and deploy from a build to a production environment.
是一系列的开发实践方法，用来确保让代码能够快速、安全的部署到产品环境中，它通过将每一次改动都提交到一个模拟产品环境中，使用严格的自动化测试，确保业务应用和服务能符合预期。因为使用完全的自动化过程来把每个变更自动的提交到测试环境中，所以当业务开发完成时，你有信心只需要按一次按钮就能将应用安全的部署到产品环境中。持续交付可以采用：CI（持续集成）、代码检查、UT（单元测试），持续部署等方式，打通开发、测试、生产的各个环节，持续的增量的交付产品。

（4） 微服务（MicroServices）：微服务首先是一个服务，其次该服务的颗粒比较小。关于微服务具体看下面讲述。

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

四、微服务

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

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

支持配置信息版本化控制，可审计，安全，配置更新不需要重启，分布式。这部分可以参考Spring Cloud Config Server、Spring Cloud Bus。
参考地址：http://blog.csdn.net/heyutao007/article/details/79462953

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）： 该模式的原理类似于电路熔断器，如果电路发生短路，熔断器能够主动熔断电路，以避免灾难性损失
参考：http://blog.csdn.net/heyutao007/article/details/51006694

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

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

这种模式比较常见的思路为：
采用微服务是首选，比如Docker。Docker是进程隔离的，单个Docker失效不会影响其他Docker容器。
把大的并行处理工作，由多个线程池来负荷分担。

（5）API网关/边缘服务
API Gateway：

对设备侧（PC,Mobile等）提供简化的单一服务接口；
它内部聚合后台几十甚至上百微服务。
价值：它的主要作用是简化设备侧开发的复杂度，减少微服务网络调用数量和网络延迟问题。