微服务架构设计方案.docx

微服务架构技术设计方案
撰写人：
版权所有：
文档版本：
初次撰写时间：
最新更新时间：
文档版本更新记录
序
版本号
更新时间
更新人员
更新内容简述
1

l网关提供了相关控制功能，高管局现有的spring Cloud与系统的
CAS如何结合使用
2、Config Server： Spring Cloud提供了远程配置中心，高管局现有的spring Cloud与系统 的的配置管理平台如何结合使用
设计阶段

1、 功能规划：对产品功能进行拆分，拆分为若干个微服务；一个功能可以创建多个微 服务并部署在多个服务器节点上，以便进行负载均衡。
2、 设计原子服务层，梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和 公共能力层，逐渐形成稳定的服务中心，使应用能更快速的响应多变的客户需求。
3、 为每个服务设计API接口（REST方式）
4、 为不同的服务进行分类，不同类型的服务需要的资源不同，可以配置不同的资源， 包括CPU、内存、存储等。
32服务拆分原则
1、 粒度微小：
根据业务功能划分服务粒度，总的原则是服务内部高内聚，服务之间低耦合。
2、 责任单一：
每个服务只做一件事，即单一职责原则。
3、 隔离性原则：
每个服务相互隔离，且不互相影响
4、业务无关优先原则：
基础服务，是一些基础组件，与具体的业务无关。比如：短信服务、邮件服务。这 里的服务最容易划分出来做微服务，也是我们第一优先级分离出来的服务。

为实现负载均衡，允许相同的服务在多个节点注册相同的服务名，不同的端口。如果没 有前期的规划，不同的服务提供者可能会注册相同的服务名，导致消费者调用服务时产生调 用混乱。
因此，需进行服务名的统一规划：
1、 规划期统一制定每个服务提供者的服务名或者模块标示。
2、 服务名的命名规则:ModuleName_ServiceName，且所有字符小写，不同单词之间以 下划线分隔。如用户管理模块提供了获取用户信息的服务，则命名为：user_get_info。
3、 新增服务名时，需要提出申请，审批通过后方可使用，为减少审批复杂度，可只审 批ModuleName，即在模块内部可以自由增加服务名，不需要进行审批。

总体原则：不同的微服务需进行物理隔离。
1、 编译策略：代码编译时，各个微服务独立编译、打包，杜绝直接的依赖；
2、 工程构建：代码开发时，各微服务创建独立的工程，工程之间不能产生直接依赖
3、 持续集成：每个微服务独立执行持续集成。

每个微服务都有自己独立的数据库，那么后台管理的联合查询会非常困难。目前通用有 四种处理方案。
1）严格按照微服务的划分来做，微服务相互独立，各微服务数据库也独立，后台需要 展示数据时，调用各微服务的接口来获取对应的数据，再进行数据处理后展示出来，这是标 准的用法，也是最麻烦的用法。
2）将业务高度相关的表放到一个库中，将业务关系不是很紧密的表严格按照微服务模
式来拆分，这样既可以使用微服务，也避免了数据库分散导致后台系统统计功能难以实现， 是一个折中的方案。
MySQL+MHA高可用架构、MySQL分布式Proxy水平扩展架构、MySQL缓存高并 发读架构、MySQL小文件系统大字段存取架构、MySQL Inforbright/Greenplum统计分析架 构。
数据库严格按照微服务的要求来切分，以满足业务高并发，实时或者准实时将各微 服务数据库数据同步到NoSQL数据库中，在同步的过程中进行数据清洗，用来满足后台业 务系统的使用，推荐使用MongoDB、HBase等。
根据系统的实际需求，我们当前采用第二种设计方案。
3・
不再采用一般的增加负载均衡服务器的方式进行负载均衡，如F5、Nginx、LVS等，而 是把负载均衡的功能以库的方式集成到服务消费方的进程内，这种方案称为软负载均衡
(Soft Load Balancing)或者客户端负载均衡。在Spring Cloud中配合Eureka的服务注册功能，
Ribbon子项目则为REST客户端实现了负载均衡。
使用Ribbon进行负载均衡，其工作原理可以概括为下面四个步骤:
1.
Ribbon首先根据其所在Zone优先选择一个负载较少的Eureka Server;
定期从Eureka Server更新并过滤服务实例列表；
根据指定的负载均衡策略，从可用的服务器列表中选择一个服务实例的地址
然后通过RestClient进行服务调用。
Ribbon本身提供了下