大神讲解微服务治理的技术演进和架构实践(转)

中生代技术群分享第四十三期

编辑：友强

讲师：李林锋

原文地址：http://mp.weixin.qq.com/s/ns_XR03hZ3t96ypYoQuJPQ

摘要：随着业务的发展,规模扩大，服务愈来愈多，须要协调线上运行的各个服务，保障服务的SLA;基于服务调用的性能KPI数据进行容量管理，合理分配各服务的资源占用;对故障业务作服务降级、流量控制、流量迁移等快速恢复业务。怎样的服务治理框架能知足需求？

 

李林锋，华为PaaS平台架构师，8年Java NIO通讯框架、平台中间件架构设计和开发经验，开源框架Netty中国推广者。精通Netty、Mina、RPC框架、企业ESB总线、分布式服务框架、云计算等技术，《Netty权威指南》、《分布式服务框架原理与实践》做者，公司总裁技术创新奖得到者

 

 

我今天分享的主题是《微服务治理的技术演进和架构实践》

本次分享，将分为三个部分。

1. 为何须要服务治理

2. 服务治理的技术演进历程

3. 云端微服务治理框架设计

 

为何须要服务治理？

第1、业务需求

随着业务的发展，服务愈来愈多，如何协调线上运行的各个服务，保障服务的SLA，对服务架构和运维人员是一个很大的挑战。随着业务规模的不断扩大，小服务资源浪费等问题逐渐显现，须要可以基于服务调用的性能KPI数据进行容量管理，合理分配各个服务的资源占用，提升机器的利用率。线上业务发生故障时，须要对故障业务作服务降级、流量控制、流量迁移等，快速恢复业务。

着开发团队的不断扩大，服务的上线愈来愈随意，甚至发生功能相同、服务名不一样的服务同时上线。上线容易下线难，为了规范服务的上线和下线，在服务发布前，须要走服务预发布流程，由架构师或者项目经理对须要上线的服务作发布审核，审核经过的才可以上线。为了知足服务线下管控、保障线上高效运行，须要有一个统一的服务治理框架对服务进行统1、有效管控，保障服务的高效、健康运行。

第2、技术需求

大部分服务化框架的服务属性经过XML配置或者Java注解的方式进行定义，以服务端流量控制为例：

服务发布的XML文件一般会打包到服务提供者的jar包中，部署在Java Web或者Java Container容器中，存储在服务端的本地磁盘中。

不管采用注解仍是XML配置的方式，若是须要在运行态动态修改服务提供者的流控阈值，都须要在本地修改配置或者修改源码，从新打包部署并升级应用。没法实如今线、配置化的修改和动态生效。因为诸如流控阈值、服务的超时时间等没法预测出最优值，须要修改以后上线验证，根据服务运行效果决定是否再作调整，所以常常须要反复调整，采用修改源码-从新打包部署-应用升级的方式进行服务治理，效率低下。所以，在技术上须要一个服务治理框架，提供Web Portal，微服务运维或者治理人员经过在线配置化的方式修改服务提供者或者消费者的属性，能够实时动态生效。

 

服务治理的技术演进历程

第一代服务治理 SOA Governance: 以IBM为首的SOA解决方案提供商推出的针对企业IT系统的服务治理框架，它主要聚焦在对企业IT系统中异构服务的质量管理、服务发布审批流程管理和服务建模、开发、测试以及运行的全生命周期管理。

第二代以分布式服务框架为中心的服务治理：随着电商和移动互联网的快速发展，基于电商平台的统一分布式服务框架的全新服务治理理念诞生，它聚焦于对内部同构服务的线上治理，保障线上服务的运行质量。相比于传统IT架构的服务治理，因为服务的开发模式、部署规模、组网类型、业务特色等差别巨大，所以服务治理的重点也从线下转移到了线上服务质量保障。

第三代以云化为核心的云端微服务治理架构：2013年至今，随着云计算和微服务架构的发展，以AWS为首的基于微服务架构   云服务化的云端服务治理体系诞生，它的核心理念是服务微自治，利用云调度的弹性和敏捷，逐渐消除人工治理。微服务架构能够实现服务必定程度的自治，例如服务独立打包、独立部署、独立升级和独立扩容。经过云计算的弹性伸缩、单点故障迁移、服务健康度管理和自动容量规划等措施，结合微服务治理，逐步实现微服务的自治。

第一代 SOA Governance服务治理

第一代SOA Service GovernanceSOA Governance的定位：面向企业IT系统异构服务的治理和服务生命周期管理，它治理的服务一般是SOA服务。传统的SOA Governance包含四部份内容：1.服务建模：验证功能需求与业务需求，发现和评估当前服务，服务建模和性能需求，开发治理规划。2.服务组装：建立服务更新计划，建立和修改服务以知足全部业务需求，根据治理策略评估服务，批准组装完成。3.服务部署：确保服务的质量，措施包括功能测试、性能测试和知足度测试，批准服务部署。4.服务管理：在整个生命周期内管理和监控服务，跟踪服务注册表中的服务，根据服务质量等级协议（SLA）上报服务的性能KPI数据进行服务质量管理。

SOA Governance 工做原理图以下所示：

传统SOA Governance的主要缺点以下：1.分布式服务框架的发展，内部服务框架须要统一，服务治理也须要适应新的架构，可以由表及里，对服务进行细粒度的管控。2.微服务架构的发展和业务规模的扩大，致使服务规模量变引发质变，服务治理的特色和难点也随之发生变化。3.缺乏服务运行时动态治理能力，面对突发的流量高峰和业务冲击，传统的服务治理在响应速度、故障快速恢复等方面存在不足，没法更敏捷应对业务需求。

 

第二代分布式服务框架服务治理

分布式服务框架的服务治理定位：面向互联网业务的服务治理，聚焦在对内部采用统一服务框架服务化的业务运行态、细粒度的敏捷治理体系。

治理的对象：基于统一分布式服务框架开发的业务服务，与协议自己无关，治理的能够是SOA服务，也能够是基于内部服务框架私有协议开发的各类服务。

治理策略：针对互联网业务的特色，例如突发的流量高峰、网络延时、机房故障等，重点针对大规模跨机房的海量服务进行运行态治理，保障线上服务的高SLA，知足用户的体验。经常使用的治理策略包括服务的限流降级、服务迁入迁出、服务动态路由和灰度发布等。

分布式服务框架典型的服务治理体系以下所示：

第三代云端微服务治理

随着云计算的发展，Dev&Ops逐渐流行起来，基础设施服务化（IaaS）为大规模、批量流水线式软件交付提供了便利，AWS作为全球最大的云计算解决方案提供商，在微服务云化开发和治理方面积累了很是多的经验，具体总结以下

1. 全公司统一服务化开发环境，统一简单化服务框架（Coral Service）,统一运行平台，快速高效服务开发；

2. 全部后端应用服务化，系统由多项服务化组件构成。

3. 服务共享、原子化、重用。

4. 服务由小研发团队（2 Pizza Team）负责服务开发、测试、部署和治理，运维整个生命周期支撑。

5. 高度自动化和Dev&Ops支持，一键式服务部署和回退。

6. 超大规模支持：后台几十万个服务，成千上万开发者同时使用，平均每秒钟有1-2个服务部署。

7. 尝试基于Docker容器部署微服务。

8.服务治理是核心：服务性能KPI统计、告警、服务健康度管理、灵活的弹性伸缩策略、故障自动迁移、服务限流和服务降级等多种治理手段，保障服务高质量运行。

 

云端微服务治理架构设计

云端微服务治理架构设计的目标以下：

1. 防止业务服务架构腐化：经过服务注册中心对服务强弱依赖进行分析，结合运行时服务调用链关系分析，梳理不合理的依赖和调用路径，优化服务化架构，防止代码腐化。

2. 快速故障定界定位：经过Flume等分布式日志采集框架，实时收集服务调用链日志、服务性能KPI数据、服务接口日志、运行日志等，实时汇总和在线分析，集中存储和展现，实现故障的自动发现、自动分析和在线条件检索，方便运维人员、研发人员进行实时故障诊断。

3. 服务微管控：细粒度的运行期服务治理，包括限流降级、服务迁入迁出、服务超时控制、智能路由、统一配置、优先级调度和流量迁移等，提供方法级治理和动态生效功能，经过一系列细粒度的治理策略，在故障发生时能够多管齐下，在线调整，快速恢复业务。

4. 服务生命周期管理：包括服务的上线审批、下线通知，服务的在线升级，以及线上和线下服务文档库的建设。

5. 灵活的资源调度：基于Docker容器，能够实现微服务的独立部署和细粒度的资源隔离。基于云端的弹性伸缩，能够实现微服务级别的按需伸缩和故障隔离。

 

云端微服务治理架构设计云端微服务治理从架构上能够分为三层：

• 第一层：微服务治理展现层，它的实现为微服务治理Portal，主要面向系统运维人员或者治理人员，提供在线、配置化的治理界面。

• 第二层：微服务治理SDK，向服务治理提供治理元数据、治理接口、以及客户端的治理类库。

• 第三层：微服务治理服务实现层，微服务治理服务，经过服务注册中心，刷新服务治理属性，同时通知服务提供者和消费者集群各节点刷新内存，使服务治理Portal下发的服务治理策略动态生效。

1.  微服务治理Portal

微服务治理Portal是微服务治理的门户，它提供服务治理操做界面，供系统运维人员或者测试人员对线上运行的微服务进行动态治理，以保障服务的SLA。

Portal框架能够基于AngularJS等Web框架进行开发，它的门户界面以下所示：能够支持同时配置多个服务注册中心集群，对不一样的微服务集群进行治理。

选择某个微服务集群以后，就能够对该集群的微服务进行治理，界面示例以下：

点击查看，能够查看微服务的状态，以及各类性能指标。点击治理，弹出选择菜单，能够对选择的微服务进行相关的治理操做。

2.  微服务治理SDK

服务治理SDK层，它主要由以下几部分组成：

1. 服务治理元数据：服务治理元数据主要包括服务治理实体对象，包括服务模型、应用模型、治理组织模型、用户权限模型、数据展现模型等。元数据模型经过Data Mapper和模型扩展，向上层界面屏蔽底层服务框架的数据模型，实现展现层和服务框架的解耦，元数据也能够用于展现界面的定制扩展；

2. 服务治理接口：服务治理Portal调用服务治理接口，实现服务治理。例如服务降级接口、服务流控接口、服务路由权重调整接口、服务迁移接口等。服务接口与具体的协议无关，它一般基于分布式服务框架自身实现，能够是Restful接口，也能够是内部的私有协议；

3. 服务治理客户端类库：因为服务治理服务自己一般也是基于分布式服务框架开发，所以服务治理Portal须要集成分布式服务框架的客户端类库，实现服务的自动发现和调用；

4. 调用示例：客户端SDK须要提供服务治理接口的参数说明、注意事项以及给出经常使用的调用示例，方便前端开发人员使用；

5. 集成开发指南：服务治理SDK须要提供集成开发指南，指导使用者如何在开发环境中搭建、集成和使用服务治理SDK。

3.  线上服务治理

线上服务治理包含多种策略，例如：流量控制、服务降级、优先级调度等。微服务启动的时候，将XML或者注解的服务提供者或者消费者属性注册到服务注册中心，由运维人员经过服务治理Portal进行在线修改，注册中心通知服务提供者和消费者刷新内存，动态生效。

下面就这几种典型的治理策略进行说明。

第1、流量控制

当资源成为瓶颈时，服务框架须要对消费者作限流，启动流控保护机制。流量控制有多种策略，比较经常使用的有：针对访问速率的静态流控、针对资源占用的动态流控、针对消费者并发链接数的链接控制和针对并行访问数的并发控制。

• 静态流控：主要针对客户端访问速率进行控制，它一般根据服务质量等级协定（SLA）中约定的QPS作全局流量控制，例如订单服务的静态流控阈值为100 QPS，则不管集群有多少个订单服务实例，它们总的处理速率之和不能超过100 QPS。

• 动态流控：它的最终目标是为了保命，并非对流量或者访问速度作精确控制。当系统负载压力很是大时，系统进入过负载状态，多是CPU、内存资源已通过载，也多是应用进程内部的资源几乎耗尽，若是继续全量处理业务，可能会致使长时间的Full GC、消息严重积压或者应用进程宕机，最终将压力转移到集群其它节点，引发级联故障。触发动态流控的因子是资源，资源又分为系统资源和应用资源两大类，根据不一样的资源负载状况，动态流控又分为多个级别，每一个级别流控系数都不一样，也就是被拒绝掉的消息比例不一样。每一个级别都有相应的流控阈值，这个阈值一般支持在线动态调整。

• 并发控制：针对线程的并发执行数进行控制，它的本质是限制对某个服务或者服务的方法过分消费，耗用过多的资源而影响其它服务的正常运行。并发控制有两种形式：针对服务提供者的全局控制和针对服务消费者的局部控制。

• 链接控制：一般分布式服务框架服务提供者和消费者之间采用长链接私有协议，为了防止由于消费者链接数过多致使服务端负载压力过大，系统须要支持针对链接数进行流控。

4.  服务降级

大促或者业务高峰时，为了保证核心服务的SLA，每每须要停掉一些不过重要的业务，例如商品评论、论坛或者粉丝积分等。

另一种场景就是某些服务由于某种缘由不可用，可是流程不能直接失败，须要本地Mock服务端实现，作流程放通。以图书阅读为例，若是用户登陆余额鉴权服务不能正常工做，须要作业务放通，记录消费话单，容许用户继续阅读，而不是返回失败。

经过服务治理的服务降级功能，便可以知足上述两种场景的需求。服务降级主要包括屏蔽降级和容错降级两种策略：

 

• 屏蔽降级：当外界的触发条件达到某个临界值时，由运维人员/开发人员决策，对某类或者某个服务进行强制降级。

它的处理流程以下所示：

第1步：运维人员以管理员身份登陆服务治理控制台，管理员具有服务治理的全套权限。

第2步：运维人员选择服务降级菜单，在服务降级界面中选择屏蔽降级。

第3步：经过服务查询界面选择须要降级的服务，注意服务的分组和版本信息，指定具体的降级策略：返回null、返回指定异常仍是执行本地Mock接口实现。第4步：服务治理Portal经过服务注册中心客户端SDK，将屏蔽降级指令和相关信息发送到服务注册中心。

第五、6步：服务注册中心接收到屏蔽降级消息后，以事件的形式下分别群发给服务提供者集群和服务消费者集群。

第7步：服务消费者接收到屏蔽降级事件通知以后，获取相关内容，更新本地缓存的服务订阅信息。当发起远程服务调用时，须要与屏蔽降级策略作匹配，若是匹配成功，则执行屏蔽降级逻辑，不发起远程服务调用。

第8步：服务提供者集群接收到屏蔽降级事件通知以后，获取相关内容，更新本地的服务发布缓存信息，将对应的服务降级属性修改成屏蔽降级。

第9步：操做成功以后，服务注册中心返回降级成功的应答消息，由服务治理Portal界面展现。

第10步：运维人员查询服务提供者列表，查看服务状态。

第11步：服务注册中心返回服务状态为屏蔽降级状态。

 

• 容错降级：当非核心服务不可用时，能够对故障服务作业务逻辑放通，以保障核心服务的运行。容错降级的工做原理以下所示：

5.  服务优先级调度

当系统当前资源很是有限时，为了保证高优先级的服务可以正常运行，保障服务SLA，须要下降一些非核心服务的调度频次，释放部分资源占用，保障系统的总体运行平稳。

服务在发布的时候，能够指定服务的优先级，若是用户没有指定，采用默认优先级策略，它的配置以下所示：

服务的优先级能够采用传统的低、中、高三级配置策略，每一个级别的执行比例能够灵活配置，以下所示：

服务发布经过扩展priority属性的方式指定优先级，服务提供者将优先级属性注册到服务注册中心并通知消费者，由消费者缓存服务的优先级，根据不一样的优先级策略进行调度。服务治理Portal经过动态修改注册中心指定服务priority属性的方式，实现运行态动态调整微服务的优先级。

 

总结除了上面介绍的几种经常使用线上治理策略，比较重要的微服务治理策略还包括：

微服务超时控制：因为微服务调用一般使用RPC方式，是同步阻塞的，所以须要设置服务调用超时时间，防止对端长时间不响应致使的应用线程挂死。超时控制支持在服务端或者消费端配置，须要支持方法级超时控制。

微服务路由策略：负载均衡策略是服务治理的重要特性，分布式服务框架一般会提供多种负载均衡策略，同时支持用户扩展负载均衡策略。经常使用的路由策略包括：

1. 随机：采用随机算法进行负载均衡，一般在对等集群组网中，随机路由算法消息分发仍是比较均匀的。

2. 轮循:按公约后的权重设置轮循比率，到达边界以后，继续绕接。

3. 服务调用时延：消费者缓存全部服务提供者的服务调用时延，周期性的计算服务调用平均时延，而后计算每一个服务提供者服务调用时延与平均时延的差值，根据差值大小动态调整权重，保证服务时延大的服务提供者接收更少的消息，防止消息堆积。

4. 一致性Hash:相同参数的请求老是发到同一个服务提供者，当某一台提供者宕机时，本来发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引发剧烈变更。

5. 粘滞链接:粘滞链接用于有状态服务，尽量让客户端老是向同一提供者发起服务调用，除非该提供者宕机，再链接另外一台。

集群容错策略：消费者根据配置的路由策略选择某个目标地址以后，发起远程服务调用，在此期间若是发生了远程服务调用异常，则须要服务框架进行集群容错，从新进行选路和调用。集群容错是系统自动执行的，上层用户并不须要关心底层的服务调用过程。集群容错和路由策略的关系以下所示：

经常使用的集群容错策略以下：  

1. Failover策略:服务调用失败自动切换策略指的是当发生RPC调用异常时，从新选路，查找下一个可用的服务提供者。一般能够配置失败切换的最大次数和间隔周期，以防止E2E服务调用时延过大。  

2. Failback策略：在不少业务场景中，消费者须要可以获取到服务调用失败的具体信息，经过对失败错误码等异常信息的判断，决定后续的执行策略，例如非幂等性的服务调用。

3. Failcache策略:Failcache策略是失败自动恢复的一种，在实际项目中它的应用场景以下：- 服务有状态路由，必须定点发送到指定的服务提供者。当发生链路中断、流控等服务暂时不可用时，服务框架将消息临时缓存起来，等待周期T，从新发送，直到服务提供者可以正常处理该消息。- 对时延要求不敏感的服务。系统服务调用失败，一般是链路暂时不可用、服务流控、GC挂住服务提供者进程等，这种失败不是永久性的失败，它的恢复是可预期的。若是消费者对服务调用时延不敏感，能够考虑采用自动恢复模式，即先缓存，再等待，最后重试。-通知类服务。例如通知粉丝积分增加、记录接口日志等，对服务调用的实时性要求不高，能够容忍自动恢复带来的时延增长。

4. Failfast策略：在业务高峰期，对于一些非核心的服务，但愿只调用一次，失败也再也不重试，为重要的核心服务节约宝贵的运行资源。此时，快速失败是个不错的选择。

服务灰度发布：灰度发布是指在黑与白之间，可以平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部用户继续用A，一部分用户开始用B，若是用户对B没有什么反对意见，那么逐步扩大范围，把全部用户都迁移到B上面来。灰度发布能够保证总体系统的稳定，在初始灰度的时候就能够发现、调整问题，以保证其影响度。

基于微服务的多版本管理机制   灰度路由策略，便可实现基于业务规则的灰度发布。

多版本管理：服务上线以后，随着业务的发展，须要对功能进行变动，或者修复线上的BUG，服务升级以后，每每须要对服务作多版本管理。服务多版本管理是分布式服务框架的重要特性，它涉及到服务的开发、部署、在线升级和服务治理。

调用分组管理：能够对服务按照业务领域、部署的DC信息、服务提供商等角度对微服务进行群组化管理，同群组之间的微服务能够自由调用，跨群组的微服务须要进行审批和受权，以实现不一样分组之间的微服务隔离。不一样分组之间能够有同名同接口的微服务的不一样实现，分组信息也是服务路由的一个因子。

全在线服务文档

相对于平台产品，业务服务的升级和修改很是频繁，传统依靠Java DOC进行接口说明和传递的方式，每每会由于缺少文档建设或API DOC没有及时刷新，致使消费者拿到的接口定义说明不许确。相比于没有文档，拿到过期、错误的API DOC文档对使用者的危害更大。

为了解决这个问题，须要创建服务文档中心，方便线上运维人员查看和多团队之间的协做，它的工做原理以下：

能够基于Swagger UI，构建微服务在线文档库，以下所示：

能够参考以下连接：https://github.com/swagger-api/swagger-ui

服务上线审批下线通知机制

当团队规模扩大以后，会划分红平台基线组、业务定制组等不一样研发团队，一些团队甚至跨多地协同开发和运维。服务的上线和下线必需要严格管控起来，一旦不合格的服务上线并被消费者消息，再想下线就很是困难了。

对于须要下线的服务管控也很重要，有些服务虽然调用频次不高，业务量也不大。可是若是贸然下线，颇有可能致使依赖它的消费者业务调用失败，这会违反服务的SLA协定，给服务提供商形成损失。

服务的上线审批、下线通知机制须要创建完善起来，它的工做原理以下所示：

除了以上介绍的经常使用服务治理措施，线下服务治理还包括：1.业务的梳理、服务划分原则和方法论；2.服务跨团队协做流程、准则、工具和方法论；3.服务的接口兼容性原则和规范；4.其它...线下服务治理依团队和业务不一样，需求也不一样，须要业务团队和服务框架团队长期梳理、实践和优化，才可以提高线下服务治理的效率，它的建设是个长期过程，并不是一蹴而就。

云端自治理

微服务弹性伸缩

基于PaaS云化平台或者Docker容器服务，能够实现基于负载的微服务弹性伸缩。

基于PaaS平台部署微服务架构示例以下：

基于Docker容器部署微服务示例以下：

基于云的动态资源调度，能够实现微服务的弹性伸缩：基于CPU、内存、磁盘、网络带宽等资源占用率的弹性伸缩策略。当VM或者容器的资源占用达到设置的阈值以后，自动执行扩容策略，动态建立微服务的运行环境，部署并运行新的微服务实例。基于业务指标的弹性伸缩策略。例如微服务的平均时延、吞吐量、成功率等。经过对微服务的性能指标进行分布式采集、汇总和计算，判断业务指标是否达到伸缩阈值，若是达到，则自动触发微服务的伸缩流程，执行弹性伸缩。用户自定义的弹性伸缩策略。能够对基于资源占用率的伸缩策略和基于业务指标的伸缩策略作组合，实现更复杂的弹性伸缩。基于云平台的微服务弹性伸缩流程以下所示：

E2E微服务生命周期管理

利用云平台对资源的动态编排和调度，能够实现基础设施自动化。利用ALM（应用生命周期管理）能够实现微服务的E2E生命周期管理。

基于Docker容器的微服务基础设施自动化流程以下所示：

微服务上线运行以后，利用云平台的ALM服务，能够对微服务进行上下线、升级、回滚等生命周期管理操做：

基于云平台提供的微服务生命周期管理服务，能够实现海量微服务的高效部署、升级和管理，而不须要关心物理基础设施的环境准备和安装，以及资源规划等，极大的提高了微服务的上线运行效率，下降了微服务的管理成本。

微服务治理全景图

微服务治理涵盖的范围很是广，不少治理手段也须要业务在实际开发中积累和沉淀，并无统一的标准，这就是实施微服务治理的困难之处。

在微服务治理发展的同时，云化和容器化革命也正在进行，结合云平台的敏捷性和弹性资源调度，微服务治理将逐步由人工治理向自动化治理演进。

微服务治理整体结构图以下所示：

Q&A

Q1：请问在实际使用时，前端网关有什么来源框架，还有分布式跟踪系统，有推荐吗？

A1: 前端网关，开源的有WSO2，基于Java语言的，GO语言的有Tyk。

 

Q2:能展开讲一下优先级调度么

A1：分布式跟踪系统打印 埋点日志比较简单，可是复杂的是后端的大数据分析。采集能够基于FLume等，后端的分析能够基于HBase   Spark

 

Q3:请教一下，对应用层扩容很容易，不少时候一个服务慢了，根本缘由是依赖的存储  数据库  外部接口的缘由，这个时候对应用层扩容解决不了问题，paas的扩容还有什么意义呢？  数据库扩容  涉及数据迁移，应用层链接池更新等等  paas不能简单扩容

A3：PaaS层的扩容一般会有几种策略：

一、基于资源使用率的扩容；

二、基于服务性能指标的扩容；

三、混合模式；

四、业务自定义扩容策略，这种场景一般是级联扩容，也就是应用依赖的服务也须要同时作扩容，例如缓存、MQ等。可是，不是全部的PaaS都支持策略4。

 

Q4:怎样从传统的系统转化到云服务上，在系统设计及技术架构有什么须要注意点。

A4: 不知道你讲的传统系统是否是指的非云系统。非云应用转到云化服务有几点设计考虑：一、服务化；二、利用云的动态性，例如弹性伸缩等；三、统一配置，使用云化的统一配置服务。

 

Q5：那mq 缓存 数据库的client都要改造  支持后端自动发现了，好多中间价的client都是配置死的，有可分享的开源实现么

A5：包括前端的URL地址，MQ服务端的URL等，云化以后，MQ等服务也是一种云化服务，例如AWS的S3服务。在咱们的实践中，原来的本地配置都统一放到了配置服务上，它是基于ZK的云化统一配置服务，地址都是从注册中心读取的，而不是本地配置。这样，就能够支持动态发现。

 

Q6：应用服务化后，涉及服务与服务之间的远程rpc，请问数据传输过程当中通常采用哪一种系列化方式，之间的优缺点都有哪些？还有场景

A6： 几种场景考量：一、若是服务看中的是标准化、开放性，对性能要求不是特别苛刻。则建议采用 Restful   JSON的方式；二、若是是内部各模块之间的服务化调用，对性能、时延要求很是高，则建议采用二进制   私有协议的方式，例如能够参考或者选择ProtocolBuf、Thrift等。一般而言，服务跟协议是解耦的，也就是说某个服务，能够同时发布成多种协议。