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

1、基于SpringCloud微服务系统设计方案微服务系统设计方案1.微服务本质微服务架构从本质上说其实就是分布式架构， 与其说是一种新架构， 不如说是一种 微服务架构风格。简单来说，微服务架构风格是要开发一种由 多个小服务组成 的应用。每个服务运 行于独 立的进程，并且采用轻量级交互。多数情况下是一个 HTTP的资源APl。这些服务具备独立 业务能力并可以通过自动化部署方式独立部署。这种风格使最小化集中管理，从而可以使 用多种不同的编程语言和数据存储技术 。对于微服务架构系统， 由于其服务粒度小， 模块化清晰，因此首先要做的是对系 统整体 进行功能、服务规划，优先考虑如何在交付过程中，从 工程实

2、践出发，组织好代码结构、配置、测试、部署、运维、监控 的整个过程，从而有效体现微服务的独立性与可部署性。本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。理解微服务架构和理念是核心。2.系统环境名称版本说明JDK1.8SPring BootSPring FrameWOrkRibbonkafkaRabbitMQ3.微服务架构的挑战可靠性：由于采用远程调用的方式， 任何一个节点、 网络出现问题， 都将使得服务调用失败， 随着微服务数量的增多，潜在故障点也将增多。 也就是没有充分的保障机制，则单点故障会大量增加。运维要求高： 系统监控、高可用性、自动化技术 分布式复杂性：网络延

3、迟、系统容错、分布式事务部署依赖性强：服务依赖、多版本问题性能（服务间通讯成本高） ： 无状态性、进程间调用、跨网络调用 数据一致性：分布式事务管理需要跨越多个节点来保证数据的瞬时一致性， 因此比起传统的单体 架构的事务，成本要高得多。另外， 在分布式系统中，通常会考虑通过数据的最终一致性来 解决数据瞬时一致带来的系统不可用。重复开发：微服务理念崇尚每个微服务作为一个产品看待， 有自己的团队开发， 甚至可以有自 己完全不同的技术、 框架， 那么与其他微服务团队的技术共享就产生了矛盾， 重复开发的工作即产生了。没有最好的，只有最适合自己的。4.架构设计4.1.思维设计微服务架构设计的根本目的是实

4、现价值交付， 微服务架构只有遵循 DeVoPS理念方可进行的更顺畅，思维方式的转变是最重要的。段实施、以及试点产品优先实施的策略 ，主要包括如下:、技术上的改进:1、前后端分离，Web前端通过Http/HttPS协议调用微服务的 APl网关，由APl网关再经过路由服务调用相应的微服务2、 不同微服务之间通过 REST方式互相调用3、 微服务之间通过消息中间件实现消息交互机制二、配套服务与功能实现 ：1、 需要进行相应的自动化服务实现， 包括自动化构建、自动化安装部署、自动化测试、 自动化平台发布（DoCker实现）2、 管理服务，对于微服务架构，必须配套相应的监控与管理服务、日志管理服务等3、

5、 协作服务，运用 DeVOPS思想提升开发、测试、运维的高效沟通与协作，实现开发 与运维的一体化4.2.微服务架构设计1、我们把整个系统根据业务拆分成若干个子系统或微服务。2、每个子系统可以部署多个应用，多个应用之间使用负载均衡。3、 需要一个服务注册中心 EUreka ,所有的服务都在注册中心注册，负载均衡也是通 过在注册中心注册的服务来使用一定策略来实现。Eureka 可部署多个，进行高可用保证。4、 所有的客户端都通过同一个网关地址访问后台的服务，通过路由配置 ZUUL网关来判断一个URL请求由哪个服务处理。请求转发到服务上的时候使用负载均衡 Ribbon。5、 服务之间采用 feign

6、 进行调用。6、 使用断路器hystrix，及时处理服务调用时的超时和错误， 防止由于其中一个服务的 问题而导致整体系统的瘫痪。7、 还需要一个监控功能，监控每个服务调用花费的时间等。8、 使用 SpringCloUd Config 进行统一的配置管理，需要考虑与公司的配置管理平台如 何配合使用。9、 HyStriX ,监控和断路器。我们只需要在服务接口上添加 HyStriX标签，就可以实现 对这个接口的监控和断路器功能。10、 HyStriX DaShbOard ,监控面板，他提供了一个界面，可以监控各个服务上的服务调 用所消耗的时间等。11、 TUrbine,监控聚合，使用 HyStriX

7、监控，我们需要打开每一个服务实例的监控信 息来查看。而 TUrbine 可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。 这样就不需要挨个打开一个个的页面一个个查看。架构的可靠性保证：在关键节点做主备、集群部署，防止单点故障。待后续确认问题：1、 ACCeSS Control: Zuul网关提供了相关控制功能，与我司 CAS如何结合使用2、 Config Server： Spring CloUd 提供了远程配置中心，与我司的配置管理平台如何结合 使用5. 设计阶段5.1.总体设计1、 功能规划 ：对产品功能进行拆分，拆分为若干个微服务；一个功能可以创建多个微 服务并部署在多个服务

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

9、业务无关。比如：短信服务、邮件服务。这 里的服务最容易划分出来做微服务，也是我们第一优先级分离出来的服务。5.3.服务规划为实现负载均衡， 允许相同的服务在多个节点注册相同的服务名， 不同的端口。 如果没 有前期的规划， 不同的服务提供者可能会注册相同的服务名， 导致消费者调用服务时产生调 用混乱。因此，需进行服务名的统一规划：1、规划期统一制定每个服务提供者的服务名或者模块标示。2、服务名的命名规则 :ModuleName_ServiceName ，且 所有字符小写 ，不同单词之间以 下划线分隔 。如用户管理模块提供了获取用户信息的服务，则命名为： user_get_info 。3、新增服务

10、名时，需要提出申请， 审批通过后方可使用 ，为减少审批复杂度，可只审 批 ModuleName ，即在模块内部可以自由增加服务名，不需要进行审批。5.4.开发策略总体原则：不同的微服务需进行 物理隔离。1、 SVN策略：SVN上创建独立的分支，不同微服务的代码提交不受相互影响；-由配置管理员统一控制。 问题：开发分支与集成分支，都将增加很多，维护工作量增加。2、 编译策略：代码编译时，各个微服务独立编译、打包， 杜绝直接的依赖 ；3、 工程构建：代码开发时，各微服务 创建独立的工程 ，工程之间不能产生直接依赖4、 持续集成：每个微服务 独立执行持续集成 。5、 版本集成：由统一的集成工具，实现

11、自动化的版本集成，将所有微服务集成到统一 的版本发布包中。5.5.版本策略每个微服务可以独立制作版本，伴随着服务的增多， SVN分支增多，版本也将增多，版 本管理的复杂度将成指数级增加。 在服务之间依赖较多时， 每个服务的升级或降级都将影响 其他服务的正常运行。因此需执行如下策略：1、 所有服务的版本制作交由专业的版本管理员执行。2、 采用自动化的版本制作策略，最大程度的减少人工操作。3、 每个服务的版本必须有详细的版本计划、版本说明，对于版本说明要制定模板，明 确需要提交的内容、版本号、 SVN标签等。4、 对项目经理的要求提升，需对整体的版本计划有严格的制定，尤其是版本之间的依 赖关系要非

12、常明确，版本升级、降级的 风险评估 需完全充分。5、接口管理： 严格执行接口管理制度， 任何接口的变更必须进行审批、 发公告等流程。5.6.数据库挑战与策略每个微服务都有自己独立的数据库， 那么后台管理的联合查询怎么处理？这应该是大家 会普遍遇到的一个问题，有三种处理方案。1)严格按照微服务的划分来做，微服务相互独立，各微服务数据库也独立，后台需要 展示数据时， 调用各微服务的接口来获取对应的数据， 再进行数据处理后展示出来， 这是标 准的用法，也是最麻烦的用法。2)将业务高度相关的表放到一个库中，将业务关系不是很紧密的表严格按照微服务模 式来拆分，这样既可以使用微服务，也避免了数据库分散导致

13、后台系统统计功能难以实现， 是一个折中的方案。3)数据库严格按照微服务的要求来切分，以满足业务高并发，实时或者准实时将各微 服务数据库数据同步到 NoSQL 数据库中，在同步的过程中进行数据清洗，用来满足后台业 务系统的使用，推荐使用 MongoDB 、HBase 等。第一种方案适合业务较为简单的小公司； 第二种方案， 适合在原有系统之上， 慢慢演化 为微服务架构的公司；第三种适合大型高并发的互联网公司。建议，我们当前采用第二种方案。5.7.负载均衡不再采用一般的增加负载均衡服务器的方式进行负载均衡，如 F5、Nginx、LVS等，而是把负载均衡的功能 以库的方式集成到服务消费方的进程内 ，这

14、种方案称为 软负载均衡(Soft Load BaIancing)或者客户端负载均衡。 在SPring CloUd中配合EUreka的服务注册功能，Ribbon子项目则为REST客户端实现了负载均衡。* 5 ； CLIEMTIj I使用Ribbon进行负载均衡，其工作原理可以概括为下面四个步骤:1.RibbOn首先根据其所在 Zone优先选择一个负载较少的 EUreka Server;2.定期从EUreka SerVer更新并过滤服务实例列表；3.根据指定的负载均衡策略，从可用的服务器列表中选择一个服务实例的地址4.然后通过ReStCIient进行服务调用。RibbOn本身提供了下面几种负载均衡

15、策略:*RoundRobinRule: 轮询策略，RibbOn以轮询的方式选择服务器，这个是默认值。所以示例中所启动的两个服务会被循环访问 ；*RandomRule:随机选择，也就是说 RibbOn会随机从服务器列表中选择一个进行访问*BestAvailableRule: 最大可用策略，即先过滤出故障服务器后，选择一个当前并发请求数最小的；*WeightedReSP On SeTimeRule: 带有加权的轮询策略，对各个服务器响应时间进行加权处理，然后在采用轮询的方式来获取相应的服务器*AVailabilityFilteri ngRule: 可用过滤策略，先过滤出故障的或并发请求大于阈值一部

16、分服务实例，然后再以线性轮询的方式从过滤后的实例清单中选出一个 ；*Zo neAvoida nceRule: 区域感知策略，先使用主过滤条件（区域负载器，选择最优区域）对所有实例过滤并返回过滤后的实例清单，依次使用次过滤条件列表中的过滤条件对主过滤条件的结果进行过滤，判断最小过滤数（默认 1）和最小过滤百分比（默认 0）,最后对满足条件的服务器则使用 RoUndRobinRule（轮询方式）选择一个服务器实例。5.8.性能策略1、 网络优化：优化组网结构，提升网络间通讯性能；2、 配置优化：优化 SPring Cloud组件集以及其他组件的配置信息，使得性能最大化。5.9.技术管理策略微服务的

17、架构理念中指出各微服务可以 独立建设，可以使用不同的技术、语言、框架等，以便能更快速的使用新技术、新框架等响应特定客户需求，解决单体应用架构更新技术、 更新框架时面临的困难或阻碍。但这也同时带来了诸多问题，如下：1、 各服务是否可以任意使用自己的技术、自己的组件、框架呢？如果这样，势必带来更大的管理困难、维护困难、技术共享困难。2、 公共的方法如何实现共享？如格式化时间的一个简单方法需要共享，也需要封装为一个服务接口吗？管理策略：1、总体原则：仍然需要进行统筹考虑，所有组件统一管理，组件放置在产品仓库中，每个产品或服务需要共享组件时，从产品仓库获取。打洁产品令洁审式.产品白店提供J、产吕. 由

18、玄户购买I兵皓芸自三的窃討2、特殊情况：特殊服务需要使用特殊的组件、框架，需提出申请，统筹规划后进行决策。6.开发阶段6.1.服务的调用 6.1.1. AIP网关调用所有服务通过ZUUl网关进行调用，不允许直接调用微服务提供者。ZUUl可能会成为系统瓶颈，在项目复杂时可考虑为 Zuul进行主备或负载均衡处理。ZIJUI储机制WrlINmWWA Urhihhb峯户端川!承CarnP4 SfFJaIRl MVBatiS*MVbatiS*MvSatis MVeatiSRPCrfiai SPringCIOUd 止路山规凹RP匚曲耀(SPringeaot.讪代理6.1.2.同步调用采用HTTP REST

19、方式进行调用，针对业务需求可以进行负载均衡， 负载均衡的调用方式有两种：1、 FeignClient2、 ReStTemPIate建议使用FeignClient方式进行服务调用。不管是什么方式，他都是通过 REST接口调用服务的http接口，参数和结果默认都是通过JaCkSon序列化和反序列化。因为 SPring MVC的ReStCOntroller定义的接口，返回的数据都是通过JaCkSOn序列化成JSON数据。6.1.3.异步调用rabbitMq、kafka、SPring Cloud Stream 均是可以选择的方案。 SPring Cloud Stream，基于 Redis、Rabbit

20、、Kafka实现的消息微服务， 简单声明模型用以在SPring Cloud应用中收发消息。6.1.4.服务间调用的权限验证般我们的APl接口都需要某种授权才能访问， 登陆成功以后，然后通过token或者cookie等方式才能调用接口。使用SPring Cloud NetfiX框架的话，登录的时候，把登录请求转发到相应的用户服务上， 登陆成功后，会设置cookie或header token等。然后客户端接下来的请求就会带着这些验证 信息，从ZUUl网关传到相应的服务上进行验证。header传到服务端，如:ZUUl网关在把请求转发到后台的服务的时候，会默认把一些Cookie、Set-CoOkie、

21、AUthOriZatiOn 。这样，客户端请求的相关 headers就可以传递到服务端,服务端设置的cookie也可以传到客户端。里通过下面的方式禁用:zuul:routes:users:path: /users/*Sen SitiVeHeaders: COOkie,Set-Cookie,Authorizati OnSerViGeId: USer冈財说了我们的某个服务有时候需要调用另一个服务，这时候，这个请求不是客户端发起，他的请求的 header里面也不会有任何验证信息。这时候，要么，通过防火墙等设置，保证服务间调用的接口，只能某几个地址访问；要么，就通过某种方式设置 header。同时，如

22、果你想在某个服务里面获得这个请求的真是 IP ,（因为请求的通过网关转发而来，你直接通过 request获得ip得到的是网关的IP），就可以从headerX-Forwarded-Host获得。如果想禁用这个 header,也可以：zuul.addProxyHeaders = false如果你使用ReStTemPIate的方式调用，可以在请求里面添加一个有 header的OPtiOnSBea nPubliC RequeSt In terceptor requestl nterceptor() return new ReqUeStI nterceptor() OVerridePUbIiC void

23、 apply(RequestTemplate template) Stri ng authToke n = getToke n(); template.header(AUTH_TOKEN_HEADER, authToke n);6.1.5.服务编排主要的作用是减少项目中的相互依赖。比如现在有项目 a调用项目b,项目b调用项目c.一直到h,是一个调用链，那么项目上线的时候需要先更新最底层的 h再更新g.更新C更新b最后是更新项目a。这只是这一个调用链，在复杂的业务中有非常多的调用，如果要 记住每一个调用链对开发运维人员来说就是灾难。有这样一个好办法可以尽量的减少项目的相互依赖， 就是服务编排，一

24、个核心的业务处理项目，负责和各个微服务打交道。比如之前是 a调用b，b掉用c, C调用d ,现在统一在一个核心项目 W中来处理，W服务使用a的时候去调用b,使用b的时候 W去调用CO其实可以理解为面向对象的设计， 减少方法之间的一层层嵌套调用， 而采取一个方法进行业务流程的串联，如方法 W实现一个完整的业务处理，则采取下面方式：function W ()1、 调用方法a;2、 调用方法b;3、 调用方法c;62服务的熔断处理在服务之间进行调用时，由于各种原因会导致远程服务不可用或压力过载等异常导致的故障蔓延，此时需要有一种机制进行保护处理。 SPring Cloud通过NetfIiX的HySt

25、riX组件实现熔断和降级 处理解决此问题。断路器（CriCUit Breaker）是一种能够在远程服务不可用时自动熔 断（打开开关），并在远程服务恢复时自动恢复 （闭合开关）的设施，SPring CloUd通过NetfIiX的HyStriX组件提供断路器、资源隔离与自我修复功能。SPring cloud HyStriX 熔断器CiFCUll BreakVr SUitD DiBIgrarnHyStriX熔断处理6.3.统一日志管理不同微服务部署在不同节点上， 登录每个节点查看日志是比较麻烦的， 同时对于需要关 联多个微服务日志联合查看分析的情况将更加麻烦。 伴随节点数量的增加，如果没有合适的 管

26、理机制与工具，定位问题、发现问题的复杂性将越来越大， 将成指数级增长，因此需要进行统一日志管理。1、 建立统一的日志管理规范；2、 开发并使用统一的日志组件，为所有微服务提供统一的日志服务，由 Iog4j或BlitZ4j 封装；3、 在每个服务节点上部署日志采集 Agent组件，由此Agent进行日志的采集与转发；4、 建立统一的日志中心，所有日志写入日志中心。说明：上述日志的实现由公司的“日志管理平台”进行实现，采用的是 ELK集合框架。6.4.统一监控管理使用HyStriX组件进行服务的监控，使用 NagioS进行服务器等资源的监控。1、 HyStriX ,监控和断路器。我们只需要在服务接

27、口上添加 HyStriX标签，就可以实现对 这个接口的监控和断路器功能。2、 HyStriX DaShbOard ,监控面板，他提供了一个界面，可以监控各个服务上的服务调 用所消耗的时间等。3、 TUrbine,监控聚合，使用 HyStriX监控，我们需要打开每一个服务实例的监控信息 来查看。而TUrbine可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。这样就不需要挨个打开一个个的页面一个个查看。6.5.统一配置管理实现各微服务的统一参数配置以及版本管理，可采用公司的配置管理平台或者 SPri ngCloud Config配置中心。SPri ng Cloud Config 配置

28、中心Cnen A CIlerl b ClIent CSPri ng Cloud Co nfig 就是我们通常意义上的配置中心。 SPring Cloud Con fig- 把应用原本放在本地文件的配置抽取出来放在中心服务器， 本质是配置信息从本地迁移到云端从而能够提供更好的管理、发布能力。SPring Cloud Config 分服务端和客户端， 服务端负责将 git （ SVn）中存储的配置文 件发布成REST接口，客户端可以从服务端 REST接口获取配置。但客户端并不能主动感知 到配置的变化，从而主动去获取新的配置，这需要 每个客户端通过 POST方法触发各自的 /refresh 。为解决

29、配置信息能及时通知到各服务， 同时减少每个微服务处理配置信息更新的复杂度，为此我们通过消息总线来解决此问题，方案如下：1.Git 仓库、Config SerVer 、以及微服务SerViCe A ”、 “SerViCe B” 的实例中都弓I入了 SPring Cloud BUS ,所以他们都连接到了 RabbitMQ的消息总线上。2.从Git仓库中配置的修改到发起 busrefresh 的PoST请求这一步可以通过 Git仓库 的 Web Hook来自动触发。3./bus/refresh 请求不再发送到具体服务实例上，而是发送给 Config SerVer ,并通过dest in ati On

30、 参数来指定需要更新配置的服务或实例。4.由于所有连接到消息总线上的应用都会接受到更新请求，所以在 WebHook中就不需要维护所有节点内容来进行更新，从而解决了通过 Web Hook来逐个进行刷新的问题。66分布式SeSSiOn采用RediS作为缓存组件以及 SeSSiOn的共享组件。6.7. REST资源响应结构制定规范和解析方法。6.8. API调用链追踪微服务架构上通过业务来划分服务的，通过 REST调用，对外暴露的一个接口，可能需要都会很多个服务协同才能完成这个接口功能， 如果链路上任何一个服务岀现问题或者网络超时，形成导致接口调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。ZiPkin，SPring Cloud SleUth主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 你只需要在Pom文件中引入相应的依赖即可。6.9.单元测试做微服务架构，进行系统测试的复杂度较大，为保证产品质量与开发、测试效率，单元 测试是必不可少的。可采用MoCk方式进行测试模拟，由持续集成进行自动化单元测试的执行以及结果输出。6.10.代码调试对于单体架构系统， 可直接本地化调试，但对于微服务架构， 接口间的调用需采用远程 通讯的方式，也就是说被调用的服务必须启动后方可被调用， 因此当微服务增多时，你可能需