文档介绍：微效劳系统设计方案
微效劳本质
微效劳架构从本质上说其实就是分布式架构， 与其说是一种新架构， 不如说是一种 微服
务架构风格。
简单来说， 微效劳架构风格是要开发一种由 多个小效劳组成 的应用。
6、使用断路器 hystrix ，及时处理效劳调用时的超时和错误， 防止由于其中一
个效劳的问题而导致整体系统的瘫痪。
7、还需要一个监控功能，监控每个效劳调用花费的时间等。
8 、使用 SpringCloud Config 进行统一的配置管理，需要考虑与公司的配置管理平台
如何配合使用。
9 、 Hystrix ，监控和断路器。我们只需要在效劳接口上添加 Hystrix 标签，就可以实
现对这个接口的监控和断路器功能。
10、 Hystrix Dashboard ，监控面板，他提供了一个界面，可以监控各个效劳上
的效劳调用所消耗的时间等。
11、Turbine ，监控聚合，使用 Hystrix 监控，我们需要翻开每一个效劳实例的监控信息来查看。 而 Turbine 可以帮助我们把所有的效劳实例的监控信息聚合到一个地方统一查看。这样就不需要挨个翻开一个个的页面一个个查看。
架构的可靠性保证：
在关键节点做主备、集群部署，防止单点故障。
待后续确认问题：
1、 Access Control
： Zuul
网关提供了相关控制功能，与我司
CAS如何结合使用
2、 Config Server
： Spring Cloud
提供了远程配置中心，与我司的配置管理平台如何
结合使用
设计阶段
. 总体设计
1、功能规划 ：对产品功能进行拆分，拆分为假设干个微效劳；一个功能可以创立多个微
效劳并部署在多个效劳器节点上，以便进行负载均衡。
2、设计 原子效劳层 ，梳理和抽取核心应用、公共应用，作为独立的效劳下沉到核心和
公共能力层，逐渐形成稳定的效劳中心，使应用能更快速的响应多变的客户需求。
3、为每个效劳 设计 API 接口 〔REST方式〕
4、为不同的 效劳进行分类 ，不同类型的效劳需要的资源不同，可以配置不同的资源，
包括 CPU、内存、存储等。
. 效劳拆分原那么
1、粒度微小：
根据业务功能划分效劳粒度，总的原那么是效劳内部高内聚，效劳之间低耦合。
2、责任单一：
每个效劳只做一件事，即单一职责原那么。
3、隔离性原那么：
每个效劳相互隔离，且不互相影响
4、业务无关优先原那么：
根底效劳，是一些根底组件，与具体的业务无关。比方：短信效劳、邮件效劳。这
里的效劳最容易划分出来做微效劳，也是我们第一优先级别离出来的效劳。
. 效劳规划
为实现负载均衡， 允许相同的效劳在多个节点注册相同的效劳名， 不同的端口。 如果没
有前期的规划， 不同的效劳提供者可能会注册相同的效劳名， 导致消费者调用效劳时产生调
用混乱。
因此，需进行效劳名的统一规划：
1、规划期统一制定每个效劳提供者的效劳名或者模块标示。
2、效劳名的命名规那么
:ModuleName_ServiceName ，且所有字符小写 ，不同单词之间以
下
划线分隔 。如用户管理模块提供了获取用户信息的效劳，那么命名为：
user_get_info
。
3、新增效劳名时，需要提出申请， 审批通过前方可使用 ，为减少审批复杂度，可只审
批 ModuleName，即在模块内部可以自由增加效劳名，不需要进行审批。
. 开发策略
总体原那么：不同的微效劳需进行 物理隔离。
1、 SVN策略： SVN上创立 独立的分支 ，不同微效劳的代码提交不受相互影响；
由配置管理员统一控制。
问题：开发分支与集成分支，都将增加很多，维护工作量增加。
2、编译策略：代码编译时，各个微效劳独立编译、打包， 杜绝直接的依赖 ；
3、工程构建：代码开发时，各微效劳 创立独立的工程 ，工程之间不能产生直接依赖
4、持续集成：每