怎样关闭系统自动更新 一篇文章带你了解Cloud Native(3)

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

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

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

1：用户提交配置更新

2：配置server更新

3：对APP A发起Refresh更新配置操作

4a：发送消息到Bus

4b：Pull 更新的配置

5a：APP C接收消息

5b：Pull更新的配置

6：其他节点同步更新

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

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

介绍两种模式：

（A）电路熔断器（Circuit Breaker）： 该模式的原理类似于电路熔断器，如果电路发生短路，熔断器能够主动熔断电路，以避免灾难性损失

正常状态下，电路处于关闭状态（Closed），调用是直接传递给依赖服务的；

如果调用出错，则进入失败计数状态；

失败计数达到一定阈值后，进入熔断状态（Open），这时的调用总是返回失败；

累计一段时间以后，保护器会尝试进入半熔断状态（Half-Open）；

处于Harf-Open状态时，调用先被传递给依赖的服务，如果成功，则重置电路状态为“Closed”，否则把电路状态置为“Open”；

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

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

采用微服务是首选，比如Docker。Docker是进程隔离的，单个Docker失效不会影响其他Docker容器。

把大的并行处理工作，由多个线程池来负荷分担。

API Gateway：

对设备侧（PC,Mobile等）提供简化的单一服务接口；

它内部聚合后台几十甚至上百微服务。

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

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

组织层面：Cloud的推行是由专门的云平台部门来完成的。云平台拉通开发、QA、运维等各个部门， 一起推动电商业务的云化。在推行Cloud过程中，我们也碰到了大部分公司都面临的“部门墙”问题。因此，目前我们在尝试“项目制”运作方式：成立一个项 目组，把相关利益责任人拉进来，由PMO推动落实。

持续交付：目前我们已经开发了CI、CD，正在并联合QA Tool工具部，线上发布系统，打通开发、QA、运维等，形成端到端的持续交付流程。持续交付的流程图如下：

敏捷基础设施

微服务：目前唯品会部分业务在尝试采用基于Docker的微服务架构，大部分还是采用SOA服务架 构。一个服务的概念，对应于我们内部的一个业务域概念，目前有1K多的业务域。随着VIP业务的快速发展，单个业务域的容量也会快速增长。因此，业务域也 在逐步的拆分中，业务域数据也会增长几倍。

12因子（Twelve-Factor）评估：由于是基于SOA架构设计，大部分可以满足12因子（Twelve-Factor）的规范。

评估参考下面表格：

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

A：过奖了，谢谢。有几点可以和大家分享一下：

技术都是慢慢积累过来的，你做的久了，自然知道的就多些，做技术贵在坚持。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/sanxing/article-58525-3.html