基于SpringCloud微服务系统设计方案.docx

微效劳系统设计方案
1. 微效劳本质
微效劳架构从本质上说其实就是分布式架构， 务架构风格。
与其说是一种新架构， 不如说是一种 微服
理解微效劳架构和理念是核心。
2.
系统环境
名称
版的配置治理，需要考虑与公司的配置治理平台
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、持续集成：每个微效劳 独立执行持续集成 。
5、版本集成：由统一的集成工具，实现自动化的版本集成，将全部微效劳集成到统一的版本公布包中。
版本策略
每个微效劳可以独立制作版本，伴随着效劳的增多，
本治理的简单度将成指数级增加。 在效劳之间依靠较多时， 其他效劳的正常运行。
因此需执行如下策略：
1、全部效劳的版本制作交由专业的版本治理员执行。
SVN 分支增多，版本也将增多，版
每个效劳的升级或降级都将影响
2、承受自动化的版本制作策略，最大程度的削减人工操作。
3、每个效劳的版本必需有具体的版本方案、版