基于SpringCloud-微服务系统设计方案【实用文档】doc

基于SpringCloud微服务系统设计方案【实用文档】doc文档可直接使用可编辑，欢迎下载

微服务系统设计方案基于SpringCloud微服务系统设计方案【实用文档】doc文档可直接使用可编辑，欢迎下载微服务本质微服务架构从本质上说其实就是分布式架构,与其说是一种新架构，不如说是一种微服务架构风格。简单来说，微服务架构风格是要开发一种由多个小服务组成的应用。每个服务运行于独立的进程,并且采用轻量级交互。多数情况下是一个ＨＴＴP的资源API。这些服务具备独立业务能力并可以通过自动化部署方式独立部署。这种风格使最小化集中管理，从而可以使用多种不同的编程语言和数据存储技术。对于微服务架构系统,由于其服务粒度小，模块化清晰,因此首先要做的是对系统整体进行功能、服务规划，优先考虑如何在交付过程中，从工程实践出发,组织好代码结构、配置、测试、部署、运维、监控的整个过程，从而有效体现微服务的独立性与可部署性.本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。理解微服务架构和理念是核心。系统环境名称版本说明JDK1。8SｐriｎgＢｏoｔSpｒiｎgFrameｗorｋRibbｏnkafkaRaｂbitMQ微服务架构的挑战可靠性：由于采用远程调用的方式,任何一个节点、网络出现问题，都将使得服务调用失败，随着微服务数量的增多，潜在故障点也将增多。也就是没有充分的保障机制，则单点故障会大量增加。运维要求高：系统监控、高可用性、自动化技术分布式复杂性：网络延迟、系统容错、分布式事务部署依赖性强:服务依赖、多版本问题性能（服务间通讯成本高）：无状态性、进程间调用、跨网络调用数据一致性：分布式事务管理需要跨越多个节点来保证数据的瞬时一致性,因此比起传统的单体架构的事务，成本要高得多。另外,在分布式系统中,通常会考虑通过数据的最终一致性来解决数据瞬时一致带来的系统不可用。重复开发：微服务理念崇尚每个微服务作为一个产品看待，有自己的团队开发,甚至可以有自己完全不同的技术、框架，那么与其他微服务团队的技术共享就产生了矛盾，重复开发的工作即产生了.没有最好的，只有最适合自己的。架构设计思维设计微服务架构设计的根本目的是实现价值交付,微服务架构只有遵循ＤｅvOpｓ理念方可进行的更顺畅,思维方式的转变是最重要的。实现微服务技术架构,现有产品需要进行技术上的改进以及相关配套服务的实现，采用分阶段实施、以及试点产品优先实施的策略，主要包括如下:一、技术上的改进： １、前后端分离,web前端通过Hｔtp/Httｐｓ协议调用微服务的ＡPI网关,由API网关再经过路由服务调用相应的微服务 ２、不同微服务之间通过REＳＴ方式互相调用 ３、微服务之间通过消息中间件实现消息交互机制二、配套服务与功能实现:ﻩ1、需要进行相应的自动化服务实现，包括自动化构建、自动化安装部署、自动化测试、自动化平台发布(Ｄｏcｋer实现） 2、管理服务,对于微服务架构，必须配套相应的监控与管理服务、日志管理服务等ﻩ3、协作服务，运用DｅvOps思想提升开发、测试、运维的高效沟通与协作，实现开发与运维的一体化微服务架构设计

1、我们把整个系统根据业务拆分成若干个子系统或微服务。

2、每个子系统可以部署多个应用，多个应用之间使用负载均衡。

3、需要一个服务注册中心Eｕreｋa,所有的服务都在注册中心注册，负载均衡也是通过在注册中心注册的服务来使用一定策略来实现。Ｅureｋa可部署多个，进行高可用保证。

4、所有的客户端都通过同一个网关地址访问后台的服务，通过路由配置ＺＵUL网关来判断一个UＲＬ请求由哪个服务处理。请求转发到服务上的时候使用负载均衡Ｒｉbｂｏn。

５、服务之间采用ｆｅｉgn进行调用。

６、使用断路器ｈｙsｔriｘ，及时处理服务调用时的超时和错误，防止由于其中一个服务的问题而导致整体系统的瘫痪。

7、还需要一个监控功能,监控每个服务调用花费的时间等。8、使用SｐｒinｇCｌouｄCoｎｆig进行统一的配置管理，需要考虑与公司的配置管理平台如何配合使用。ﻩ9、Hyｓｔrｉｘ,监控和断路器。我们只需要在服务接口上添加Hｙstｒiｘ标签，就可以实现对这个接口的监控和断路器功能.

10、HysｔrixＤasｈboard，监控面板，他提供了一个界面，可以监控各个服务上的服务调用所消耗的时间等。

１１、Turbinｅ，监控聚合，使用Hystｒiｘ监控，我们需要打开每一个服务实例的监控信息来查看。而Turbｉｎe可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。这样就不需要挨个打开一个个的页面一个个查看.架构的可靠性保证：在关键节点做主备、集群部署，防止单点故障.待后续确认问题:ﻩ1、AccessＣoｎｔｒol:Ｚuｕl网关提供了相关控制功能，与我司CAＳ如何结合使用 2、ConfigＳeｒvｅｒ:ＳｐringCloud提供了远程配置中心,与我司的配置管理平台如何结合使用设计阶段总体设计 1、功能规划:对产品功能进行拆分,拆分为若干个微服务；一个功能可以创建多个微服务并部署在多个服务器节点上，以便进行负载均衡.ﻩ２、设计原子服务层，梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使应用能更快速的响应多变的客户需求。ﻩ３、为每个服务设计AＰI接口（REＳＴ方式）ﻩ4、为不同的服务进行分类，不同类型的服务需要的资源不同，可以配置不同的资源,包括ＣPU、内存、存储等.服务拆分原则ﻩ1、粒度微小:根据业务功能划分服务粒度，总的原则是服务内部高内聚，服务之间低耦合。2、责任单一：每个服务只做一件事，即单一职责原则. 3、隔离性原则:每个服务相互隔离，且不互相影响ﻩ４、业务无关优先原则:基础服务，是一些基础组件,与具体的业务无关。比如：短信服务、邮件服务。这里的服务最容易划分出来做微服务,也是我们第一优先级分离出来的服务。服务规划为实现负载均衡，允许相同的服务在多个节点注册相同的服务名,不同的端口.如果没有前期的规划，不同的服务提供者可能会注册相同的服务名，导致消费者调用服务时产生调用混乱.因此，需进行服务名的统一规划：１、规划期统一制定每个服务提供者的服务名或者模块标示。２、服务名的命名规则:ＭｏduleNaｍe＿SerｖiceNａme，且所有字符小写，不同单词之间以下划线分隔.如用户管理模块提供了获取用户信息的服务，则命名为：uｓｅｒ＿get_ｉnfｏ.3、新增服务名时,需要提出申请,审批通过后方可使用，为减少审批复杂度，可只审批ＭoｄuleNａmｅ,即在模块内部可以自由增加服务名，不需要进行审批。开发策略总体原则：不同的微服务需进行物理隔离。ﻩ1、SＶN策略:SVN上创建独立的分支,不同微服务的代码提交不受相互影响;－--由配置管理员统一控制。问题：开发分支与集成分支，都将增加很多，维护工作量增加.ﻩ2、编译策略：代码编译时，各个微服务独立编译、打包,杜绝直接的依赖; 3、工程构建：代码开发时，各微服务创建独立的工程,工程之间不能产生直接依赖 ４、持续集成:每个微服务独立执行持续集成. 5、版本集成：由统一的集成工具，实现自动化的版本集成,将所有微服务集成到统一的版本发布包中.版本策略每个微服务可以独立制作版本，伴随着服务的增多,ＳＶN分支增多，版本也将增多，版本管理的复杂度将成指数级增加。在服务之间依赖较多时，每个服务的升级或降级都将影响其他服务的正常运行。因此需执行如下策略：ﻩ1、所有服务的版本制作交由专业的版本管理员执行.ﻩ2、采用自动化的版本制作策略，最大程度的减少人工操作.ﻩ３、每个服务的版本必须有详细的版本计划、版本说明，对于版本说明要制定模板,明确需要提交的内容、版本号、SVN标签等.4、对项目经理的要求提升，需对整体的版本计划有严格的制定，尤其是版本之间的依赖关系要非常明确,版本升级、降级的风险评估需完全充分。5、接口管理：严格执行接口管理制度，任何接口的变更必须进行审批、发公告等流程。数据库挑战与策略每个微服务都有自己独立的数据库,那么后台管理的联合查询怎么处理？这应该是大家会普遍遇到的一个问题,有三种处理方案。1)严格按照微服务的划分来做，微服务相互独立，各微服务数据库也独立,后台需要展示数据时,调用各微服务的接口来获取对应的数据,再进行数据处理后展示出来,这是标准的用法，也是最麻烦的用法。2）将业务高度相关的表放到一个库中,将业务关系不是很紧密的表严格按照微服务模式来拆分，这样既可以使用微服务，也避免了数据库分散导致后台系统统计功能难以实现，是一个折中的方案。3)数据库严格按照微服务的要求来切分，以满足业务高并发，实时或者准实时将各微服务数据库数据同步到NoＳＱL数据库中,在同步的过程中进行数据清洗，用来满足后台业务系统的使用，推荐使用ＭoｎgoDB、HＢaｓe等。第一种方案适合业务较为简单的小公司；第二种方案，适合在原有系统之上，慢慢演化为微服务架构的公司;第三种适合大型高并发的互联网公司。建议,我们当前采用第二种方案.负载均衡不再采用一般的增加负载均衡服务器的方式进行负载均衡，如F5、Ｎｇinx、LVS等，而是把负载均衡的功能以库的方式集成到服务消费方的进程内，这种方案称为软负载均衡(SｏｆtLoadＢａlanciｎg）或者客户端负载均衡。在ＳｐｒingCloud中配合Eurｅｋa的服务注册功能，Ribbｏｎ子项目则为ＲＥST客户端实现了负载均衡。使用Ribbｏｎ进行负载均衡,其工作原理可以概括为下面四个步骤：Rｉbbｏn首先根据其所在Ｚonｅ优先选择一个负载较少的ＥurekaSｅｒｖｅr；定期从EuｒekaSｅｒveｒ更新并过滤服务实例列表；根据指定的负载均衡策略，从可用的服务器列表中选择一个服务实例的地址;然后通过ReｓtClｉenｔ进行服务调用。Rｉbｂoｎ本身提供了下面几种负载均衡策略:RounｄRobinRule：

轮询策略，Rｉbbon以轮询的方式选择服务器，这个是默认值。所以示例中所启动的两个服务会被循环访问;RaｎdomRulｅ:

随机选择,也就是说Ribbｏn会随机从服务器列表中选择一个进行访问；BｅstAvailableRule:

最大可用策略，即先过滤出故障服务器后，选择一个当前并发请求数最小的；WｅightedＲｅsponseTｉｍeRｕle：

带有加权的轮询策略,对各个服务器响应时间进行加权处理，然后在采用轮询的方式来获取相应的服务器；AvaｉlaｂilityFilｔｅrｉngＲule:

可用过滤策略，先过滤出故障的或并发请求大于阈值一部分服务实例,然后再以线性轮询的方式从过滤后的实例清单中选出一个;ＺonｅAvoidaｎｃeRｕle:

区域感知策略，先使用主过滤条件(区域负载器，选择最优区域）对所有实例过滤并返回过滤后的实例清单,依次使用次过滤条件列表中的过滤条件对主过滤条件的结果进行过滤，判断最小过滤数（默认1)和最小过滤百分比（默认０），最后对满足条件的服务器则使用RoundRobinRuｌe(轮询方式）选择一个服务器实例.性能策略ﻩ１、网络优化:优化组网结构，提升网络间通讯性能；2、配置优化:优化SpriｎgClｏud组件集以及其他组件的配置信息，使得性能最大化。技术管理策略微服务的架构理念中指出各微服务可以独立建设，可以使用不同的技术、语言、框架等，以便能更快速的使用新技术、新框架等响应特定客户需求，解决单体应用架构更新技术、更新框架时面临的困难或阻碍。但这也同时带来了诸多问题，如下:ﻩ1、各服务是否可以任意使用自己的技术、自己的组件、框架呢？如果这样，势必带来更大的管理困难、维护困难、技术共享困难。ﻩ２、公共的方法如何实现共享？如格式化时间的一个简单方法需要共享,也需要封装为一个服务接口吗？管理策略： 1、总体原则：仍然需要进行统筹考虑，所有组件统一管理，组件放置在产品仓库中,每个产品或服务需要共享组件时,从产品仓库获取。ﻩ２、特殊情况：特殊服务需要使用特殊的组件、框架,需提出申请，统筹规划后进行决策.开发阶段服务的调用AIP网关调用所有服务通过Zｕuｌ网关进行调用,不允许直接调用微服务提供者.Zuul可能会成为系统瓶颈,在项目复杂时可考虑为Zuul进行主备或负载均衡处理。同步调用采用HTＴPREST方式进行调用，针对业务需求可以进行负载均衡,负载均衡的调用方式有两种: 1、FeigｎＣｌiｅnt ２、RestＴemplatｅ建议使用FeignClieｎt方式进行服务调用.不管是什么方式，他都是通过ＲEＳＴ接口调用服务的http接口，参数和结果默认都是通过Ｊacｋson序列化和反序列化。因为ＳpｒiｎgMＶC的RestCoｎtｒolleｒ定义的接口，返回的数据都是通过Jackson序列化成ＪSON数据.异步调用 ｒabbitMｑ、kaｆka、SpｒiｎgCloudStream均是可以选择的方案。ＳｐrｉnｇClouｄStreａm，基于Rｅｄis、Rabbit、Kafka实现的消息微服务，简单声明模型用以在SprinｇCloud应用中收发消息.服务间调用的权限验证一般我们的API接口都需要某种授权才能访问，登陆成功以后，然后通过tokeｎ或者cooｋiｅ等方式才能调用接口。使用SpringCｌouｄNeｔｆｉｘ框架的话，登录的时候，把登录请求转发到相应的用户服务上，登陆成功后,会设置cｏoｋｉe或ｈeadｅrtｏｋｅn等.然后客户端接下来的请求就会带着这些验证信息,从Zuｕl网关传到相应的服务上进行验证。Zuul网关在把请求转发到后台的服务的时候，会默认把一些hｅadeｒ传到服务端，如：Ｃooｋie、Set—Cookｉe、Authoriｚatｉｏn。这样，客户端请求的相关headeｒｓ就可以传递到服务端，服务端设置的coｏｋｉe也可以传到客户端。但是,如果你想禁止某些header透传到服务端,可以在Ｚｕul网关的apｐｌicａtiｏｎ.yml配置里通过下面的方式禁用：zuul：ﻫroｕtes:

users：ﻫpaｔh：/userｓ/**ﻫｓensitiｖｅHeadeｒｓ：Cｏoｋｉe，Seｔ-Ｃookｉe，Autｈoｒiｚaｔion

serviceId:usｅr刚才说了我们的某个服务有时候需要调用另一个服务，这时候，这个请求不是客户端发起，他的请求的headｅr里面也不会有任何验证信息。这时候，要么,通过防火墙等设置，保证服务间调用的接口,只能某几个地址访问；要么，就通过某种方式设置ｈeａdｅr。同时，如果你想在某个服务里面获得这个请求的真是ＩP，（因为请求的通过网关转发而来，你直接通过reqｕest获得ip得到的是网关的IP)，就可以从headeｒX—Ｆorwaｒded—Ｈosｔ获得.如果想禁用这个heａdeｒ,也可以:zuul。ａddＰroxyHｅadｅrs＝false如果你使用RｅstTeｍｐlate的方式调用，可以在请求里面添加一个有ｈｅａdeｒ的Ｏｐtｉons。也可以通过如下的拦截器的方式设置，它对ＲestTemplatｅ方式和FｅignClient的方式都可以起作用：@ＢeanﻫｐublｉcRｅquｅstIntercｅptoｒrequｅstIｎterｃｅptor（){

ｒeｔurnnewＲｅqｕｅｓtIntercepｔor（）｛ﻫ@Ovｅrrideﻫpuｂlicｖoidapply(RequesｔTemplatetｅmplate){

StriｎgaｕthＴｏken＝ｇetToｋen（);ﻫtemplａｔe．headｅr（AUTH_TＯKEN＿HEAＤER,ａuｔhTokｅn）;

}ﻫ｝；

｝服务编排主要的作用是减少项目中的相互依赖。比如现在有项目a调用项目b，项目b调用项目ｃ。。.一直到h,是一个调用链,那么项目上线的时候需要先更新最底层的ｈ再更新g.。.更新c更新b最后是更新项目a。这只是这一个调用链，在复杂的业务中有非常多的调用，如果要记住每一个调用链对开发运维人员来说就是灾难.有这样一个好办法可以尽量的减少项目的相互依赖,就是服务编排,一个核心的业务处理项目，负责和各个微服务打交道。比如之前是a调用b,ｂ掉用c，c调用d，现在统一在一个核心项目Ｗ中来处理,W服务使用a的时候去调用b,使用b的时候W去调用c。其实可以理解为面向对象的设计,减少方法之间的一层层嵌套调用,而采取一个方法进行业务流程的串联,如方法W实现一个完整的业务处理，则采取下面方式: ｆunｃtiｏｎw（）ﻩ{ 1、调用方法ａ； 2、调用方法ｂ;ﻩ3、调用方法c；｝服务的熔断处理在服务之间进行调用时,由于各种原因会导致远程服务不可用或压力过载等异常导致的故障蔓延,此时需要有一种机制进行保护处理。SpriｎｇCloｕd通过Netｆlix的Hysｔrix组件实现熔断和降级处理解决此问题。断路器(ＣriｃuiｔBreakｅr)是一种能够在远程服务不可用时自动熔断(打开开关），并在远程服务恢复时自动恢复（闭合开关)的设施,ＳprｉｎｇCｌoud通过Nｅtｆｌix的Ｈyｓtｒix组件提供断路器、资源隔离与自我修复功能.SｐriｎgcloｕdHystｒix熔断器统一日志管理不同微服务部署在不同节点上，登录每个节点查看日志是比较麻烦的，同时对于需要关联多个微服务日志联合查看分析的情况将更加麻烦。伴随节点数量的增加，如果没有合适的管理机制与工具，定位问题、发现问题的复杂性将越来越大,将成指数级增长，因此需要进行统一日志管理.ﻩ１、建立统一的日志管理规范；ﻩ2、开发并使用统一的日志组件，为所有微服务提供统一的日志服务，由log4j或Blitz4ｊ封装； ３、在每个服务节点上部署日志采集Aｇｅnt组件,由此Ａgｅｎt进行日志的采集与转发;4、建立统一的日志中心,所有日志写入日志中心。说明:上述日志的实现由公司的“日志管理平台"进行实现，采用的是ＥＬＫ集合框架。统一监控管理使用Hｙstrix组件进行服务的监控，使用Ｎagios进行服务器等资源的监控。 1、Hysｔrix，监控和断路器。我们只需要在服务接口上添加Hystｒiｘ标签，就可以实现对这个接口的监控和断路器功能。

2、HyｓtrixDasｈboaｒｄ,监控面板，他提供了一个界面,可以监控各个服务上的服务调用所消耗的时间等。

3、Tｕrbｉnｅ，监控聚合,使用Hｙｓtriｘ监控，我们需要打开每一个服务实例的监控信息来查看。而Tuｒbinｅ可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看.这样就不需要挨个打开一个个的页面一个个查看.统一配置管理实现各微服务的统一参数配置以及版本管理，可采用公司的配置管理平台或者SｐringCloｕdConfｉg配置中心.ＳprｉngCｌoudCｏnfig配置中心SprｉngClｏudCoｎfiｇ就是我们通常意义上的配置中心。SｐriｎｇCloudＣonｆig－把应用原本放在本地文件的配置抽取出来放在中心服务器,本质是配置信息从本地迁移到云端.从而能够提供更好的管理、发布能力。ＳpｒｉｎgCloudConfiｇ分服务端和客户端，服务端负责将git（svn）中存储的配置文件发布成RESＴ接口，客户端可以从服务端RＥＳＴ接口获取配置。但客户端并不能主动感知到配置的变化,从而主动去获取新的配置,这需要每个客户端通过ＰOＳT方法触发各自的／refresh。为解决配置信息能及时通知到各服务，同时减少每个微服务处理配置信息更新的复杂度，为此我们通过消息总线来解决此问题，方案如下：Git仓库、ConfigSeｒver、以及微服务“ＳervicｅA”、“SerｖiceB”的实例中都引入了SprｉngCloｕdBｕs，所以他们都连接到了ＲaｂbｉtMQ的消息总线上。从Gｉt仓库中配置的修改到发起／ｂus/reｆｒesh的POST请求这一步可以通过Gｉt仓库的WebHook来自动触发。/bus/refrｅsh请求不再发送到具体服务实例上,而是发送给ＣonfigSeｒver，并通过desｔination参数来指定需要更新配置的服务或实例.由于所有连接到消息总线上的应用都会接受到更新请求,所以在ＷebHook中就不需要维护所有节点内容来进行更新,从而解决了通过ＷｅbHooｋ来逐个进行刷新的问题。分布式seｓｓion采用Ｒedis作为缓存组件以及sessioｎ的共享组件。RＥST资源响应结构制定规范和解析方法。ＡPI调用链追踪微服务架构上通过业务来划分服务的，通过REＳT调用，对外暴露的一个接口,可能需要很多个服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，都会形成导致接口调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。ＳpｒingCｌoｕdSｌeｕｔｈ主要功能就是在分布式系统中提供追踪解决方案,并且兼容支持了ziｐｋin，你只需要在poｍ文件中引入相应的依赖即可.单元测试做微服务架构，进行系统测试的复杂度较大,为保证产品质量与开发、测试效率，单元测试是必不可少的。可采用Mock方式进行测试模拟，由持续集成进行自动化单元测试的执行以及结果输出。代码调试对于单体架构系统,可直接本地化调试，但对于微服务架构，接口间的调用需采用远程通讯的方式，也就是说被调用的服务必须启动后方可被调用,因此当微服务增多时，你可能需要启动大量的微服务或者web服务器,这给本地化调用与调试带来了困难。解决方案待研究.测试自动化测试单元测试:由开发人员实现。采用Ｍｏcｋ方式进行测试模拟，由持续集成进行自动化单元测试的执行以及结果输出。业务测试:开发进行实现,测试也需考虑如何实现。将多个服务或业务单元进行串联，测试一个完整的业务,甚至是不同业务之间组成的系统测试，需要采用相关的自动化测试框架执行，如ＲｏboｔFraｍeｗorｋ自动化测试框架。依赖测试也可以称为接口测试或者契约测试，在微服务逐渐增多的情况下，如何有效保证服务之间能够按照接口的约定正常工作，即符合契约，成为微服务实施过程中，测试面临的主要挑战。一、开发自动化的接口测试工具,ﻩ1、检测接口是否满足约定ﻩ2、检测接口是否发生变化 3、检测接口是否可以正常被调用。二、测试方法：采取基于消费者驱动的契约测试，测试架构如下：其优势如下:从价值实现的角度定义契约从消费者使用契约的角度出发,首先保证消费者基于此契约是可以实现价值的，有了这个前提,再使用契约来验证提供者，如果提供者提供的契约同定义的契约一致，则证明提供者提供的契约是能够实现服务消费者的。通过这种方式,使得更聚焦于如何从价值实现出发.隔离消费者和提供者的测试对于契约的消费者和提供者可以分开独立测试，有效解决传统集成测试服务架构的弊端，将微服务的接口测试成本降到最低.三、测试工具：ﻩPacｔ、Ｊaｎus、Pactｏ等。系统测试熔断测试 1、通过停止微服务的方式测试服务路由的正确性ﻩ２、通过压力测试，将某个微服务产生过载等异常，测试服务熔断或降级 3、通过压力测试，测试负载均衡策略的正确性性能测试原有本地化的api调用将会变成RESＴ的远程调用,调用速度势必受到影响，因此需要对系统性能进行考虑以及性能测试,主要影响因素如下：1、网络：远程调用时受到网络通讯速度的影响，这涉及到网络速度、网络部署以及系统架构，有相互依赖的服务应采取就近部署原则.2、服务器：受到远程服务所在服务器性能的影响.3、数据量:数据量这里指的是数据大小以及数据传输的次数以及频率,此时RＥST调用方式会产生瓶颈，当然,最好的方式是避免此种情况发生，此种场景采取消息中间件的方式异步通讯。持续集成ﻩ1、持续集成:每个微服务独立执行持续集成。 2、版本集成：由统一的集成工具,实现自动化的版本集成，将所有微服务集成到统一的版本发布包中。 3、持续集成可制作多种场景的版本，包括测试环境、开发环境、生产环境。ﻩ４、统计测试覆盖率等指标数据。 ５、工具：Jｅｎkｉns、Sｏnar等.持续部署 １、通过持续集成自动制作发布版本的Docｋer镜像;ﻩ２、将docker镜像自动上传到dｏｃker容器中.运维阶段远程升级微服务不断增加后，意味着部署容器也在同步增加,对于后续升级维护的工作量将会逐渐增加，开发统一管理中心,支持远程维护与升级将可减少运维的复杂度。统一配置中心使用SpringCｌoudConfig或者配置管理平台进行统一的配置管理。统一日志中心使用日志管理平台进行统一的日志采集、日志分析.基于ＬｏRａ的组网设计方案目录1概述 １HＹPERLINK\l＂＿Toc９4７３"２功能性能指标 １HYPERLINＫ\l"_Toc441０”2.1功能指标 1HYＰERＬINＫ\l＂_Toc1577８”2.2性能指标 23技术路线选择 ３ＨYＰEＲLＩNK\l＂_Ｔoc139８0"4系统设计ﻩ44.1系统组成ﻩ4HYPERLＩNK4。2系统工作模式 5HＹPERLINK\l＂_Tｏｃ１６680"4.2。1主机轮询的组网方式 ６4．2。2分时间片的组网方式ﻩ６５通信设计 7HＹPERLＩNＫ\l”_Ｔoc２6３８5”5.1ＭODBＵS通信协议ﻩ7５.2MODBＵS通信示意图 8HYPEＲLINK\l"_Toc1３145"６软件设计ﻩ8ＨYPERＬINK\l”＿Toｃ25２2"6.１软件流程图ﻩ8６．2软件时序图 9ＨYPERＬINＫ\l”＿Toc319４＂7结构设计 107。1接口设计ﻩ10７.2外形设计 1１ＨYPERLＩＮＫ\l＂_Tｏc２０36５"８实验方案ﻩ129项目进度和质量保证ﻩ１39。１项目研制进度计划ﻩ13ＨYPERLINＫ\l”_Ｔｏc21２9３＂9.２质量控制与文件交付进度计划ﻩ1４１0主机与监测系统通信协议 1４HYPEＲＬINK\l”＿Tｏc290８５”10．1概述 1４HYPERLＩＮK１０．2协议标准设置ﻩ1410.3字节格式ﻩ１５1０.4帧格式 15ＨYPERＬIＮK\l”_Toc１1348”10．5浮点数存贮和传输格式 16ＨYPＥＲLIＮK10．6功能码ﻩ16HYPEＲLIＮK１0。9异常响应ﻩ１910.10CRC16校验方式 １９1概述基于LoＲa的组网通信系统采用LoRａ通信协议进行组网通信,系统由计算机终端、通信基站、集成通信模块的用户设备、具备通信功能的用户设备等组成，实现整套系统的互相通信.2功能性能指标2.１功能指标ＬoRa组网通信功能：通过通信基站向全部设备广播信息;通过通信基站向某一特定设备发送参数或控制命令;通信基站同时接收１6个设备的上传数据。LｏRａ通信加密功能：无线通信具备加密功能，提供加密算法.设备命名功能:为每一个接入网络的设备定义设备编号，名字可长期不变,也可经授权改变,可唯一识别不同的设备，满足后续数据处理。485通信功能：按照485标准以及MODＢUS数据格式，通信模块可完成与用户模块电路之间的数据通信.调试界面软件功能:实时显示各设备数据,包括设备工作状态、设备传感器数据;设置设备参数与状态，包括设备命名与修改、下达复位命令、设置报警值、设置数据上传时间间隔、启停数据采集等;存储数据，按照不同任务、不同设备进行关联存储;数据可查询;数据可打印。AＰI接口通信功能：按照MＯDＢＵＳ数据格式和LｏRa通信协议，建立界面软件(包括调试界面软件)和通信基站之间通信通道，界面软件可实现相应功能。故障显示与定位功能:当通信基站和通信模块发生故障时，界面可显示故障，并显示具体哪一个通信模块或通信基站发生故障。２。2性能指标无线通信体制:LoRa通信，一个基站对多个通信设备的组网通信。无线通信距离：无遮挡传输距离≥5０00ｍ,有金属遮挡传输距离≥20０0ｍ.无线通信速率:通信基站向用户设备下传数据≥1kbpｓ；用户设备向通信基站上传数据≥５kbpｓ；通信基站数据吞吐速率≥１０kbps,可同时接收≥16路的设备上传数据;有遮挡时,上传和下传数据率的衰减量≤50%。通信模块供电:采用+12V电源供电。通信基站功耗:通过DC12V电源适配器进行设备供电。数据加密：无线通信上传和下传数据进行加密,16路同时上传时,数据吞吐速率不超过通信基站额定能力的70％。提供数据加解密算法.485通信速率:通信模块向用户模块电路的下传数据速率≥１kｂｐｓ;用户模块电路向通信模块的上传数据速率≥5ｋｂｐs；数据格式采用ＭODＢＵＳ通讯协议。一次工作时间：一次开机,可可靠连续工作12h.工作温度：－3５℃~55℃。存储温度:-40℃～70℃.湿度:４0℃工作温度下，9０％湿度，通信基站、通信模块能正常工作，且不凝露。元器件和原材料的性能参数满足环境温度（工作温度、存储温度）要求。3技术路线选择LoRａ是LPWAN(低功耗广域物联网）通信技术中的一种，LoＲa作为目前最有发展前景的低功耗广域通信技术,已经被运用在个各行各业中。是美国Semｔech公司采用和推广的一种基于扩频技术的超远距离无线传输方案。LoRa无线通信采用直序扩频技术，具有通信距离远、功率密度集中，抗干扰能力强的优势.同时具有软件FEＣ前向纠错算法,其编码效率较高,纠错能力强，在突发干扰的情况下，能主动纠正被干扰的数据包,大大提高可靠性和传输距离.目前,LoRa主要在全球免费频段运行，包括433、8６8、915ＭHz等.ＬoRａ是物联网应用中的无线技术有多种,可组成局域网或广域网。ZigＢee是一种无线连接,可工作在2．4GHz（全球流行）、868MHｚ(欧洲流行)和91５MHz（美国流行）３个频段上，是一种近距离、低复杂度、低功耗、低速率、低成本的双向无线通讯技术。基于此，我们选择传输距离远、功耗低(长电池寿命）的LoRa模块。４系统设计基于LoＲa的组网通信系统由计算机终端、通信基站、集成通信模块的用户设备、具备通信功能的用户设备等组成，系统采用LoＲa通信协议进行组网通信，实现命令或参数的下达，以及数据的采集与上传等功能.图4．1基于ＬoRａ的组网通信系统组成示意图4。1系统组成系统由计算机终端、通信基站、集成通信模块的用户设备（设备1~设备10)、具备通信功能的用户设备(设备11～设备1６）等组成.表SＥQ表\＊ＡRABIC１设备清单序号名称数量说明1通信基站1台提供技术手册。2通信模块10块提供技术手册.3基站天线1套SMA接口；提供技术手册。４设备天线10套防水、防尘；ＳMA接口；提供技术手册。５通信模块电缆１0套每套含:一根300mm的SMA电缆；一根300mm的485通信电缆（含接插件，提供定义，3个信号线）；一根30０mm的供电电缆（SMA接口）;一根48５转UＳB电缆。6AＰＩ接口软件1套提供使用说明书。7LoRa通信协议与MODBUS数据格式１套采用该通信协议和数据格式，可满足其他设备实现LoRａ通信功能设计.8调试界面软件1套供系统集成调试用,提供说明书。4。２系统工作模式因射频的特性决定了无线串口收发模块可以一发多收,不能同时多发一收,造成了射频组网的最大的障碍，因此,为了解决这个问题就只能够利用时间来实现组网，下面是无线LoRa收发模块实现多发一收的解决方案。4．２.1主机轮询的组网方式主机轮询方式组网是主机逐个查询的方式，该组网方式能够准确上传,并且相互设备之间不容易出现冲突，组网也比较稳定,但是缺点是主机轮询耗时间长。这种组网方式适合那些对时间要求不高的组网应用。主机轮询的组网方式原理很简单,通过点名的方式实现应答.如主机发送给1号从机，由于从机都有地址设别，因此只有从机1能够响应主机。从机1收到主机的命令后,将数据上传给主机。主机再以相同点的轮询方式轮询其它从机数据.图4。２主机轮询组网图4。2．2分时间片的组网方式分时间片的组网方式对于组网数据收集来说是比简单的轮询方式快了很多，但是对从机的时间同步以及发送延迟要求高。图4.3分时间片组网图如图,这种组网方式是先由主机发起广播时间，从机收到后,同步自己的本地时间，同步完成后，根据自己的编号进行延时上传,从而实现多发一收的功能.这种组网方式收发数据时间节省很多，并且能够防止冲突，但是对软件延时等调整要求较高。为保证数据传输的实时性，选择第二种方式分时间片的组网方式，实现整个系统的无线通信。5通信设计５.１MＯＤBＵS通信协议ＭODBUS网络是一个工业通信系统,由带智能终端的可编程序控制器和计算机通过公用线路或局部专用线路连接而成。其系统结构既包括硬件、亦包括软件。它可应用于各种数据采集和过程监控。它已经成为一种通用工业标准。ＭODBUＳ网络只有一个主机，所有通信都由它发出。网络可支持247个之多的远程从属控制器,但实际所支持的从机数要由所用通信设备决定。MＯＤBＵS协议定义了一个控制器能认识使用的消息结构,而不管它们是经过何种网络进行通信的。它描述了一个控制器请求访问其它设备的过程，如何回应来自其它设备的请求,以及怎样侦测错误并记录。它制定了消息域格局和内容的公共格式。MODＢUS网络以ＲTU模式进行通信，在消息中的每个8Bit字节按照原值传送，不做处理。这种方式的主要优点是：数据帧传送之间没有间隔,相同波特率下传输数据的密度要比ＡSCＩI高，传输速度更快。5.２MODBUS通信示意图本系统由无线LoRa和有线485进行组网通信。均采用ＭＯDBUS通信协议RTＵ通信方式。可进行点对点通信和点（基站）对多(模块）通信。图5.1基于ＬoRa的通信示意图软件设计6。1软件流程图监测主机界面软件主要对整个系统的运行状况进行监控。出现异常情况时，给出报警提示;同时可进入设置界面进行参数设置，对历史数据存储和打印.图6。1监测主机软件流程图6.2软件时序图监测主机界面软件可通过无线LｏＲa或者有线４8５进行通信。监测主机作为主机，可对任一设备进行点对点通信，也可通过广播命令控制所有从机，当主机获取所有从机数据时,从机根据设备编号延时间隔固定时间依次回应数据。图6．2监测主机软件时序图7结构设计通信基站和通信模块采用如图所示外形结构和安装尺寸，包括各接口定义。７．1接口设计图７.１电气接口示意图图7.2状态指示图表2电气接口定义表脚号名称功能说明1DB-９母型插座RS—２32接口标准RＳ－2３2接口2３．81接线端子RS—4８5、电源接口标准RS－232接口与压线式电源接口3ＰＷR-ＬＥD电源指示灯红色,电源接通时点亮4TXD—LＥD发送指示灯黄色，发送数据时闪烁5RXD—LED接收指示灯黄色，接收数据时闪烁6DC电源接口电源接口直插式圆孔5。5＊2.５mm7拨码开关拨码开关工作模式控制8天线接口ＳMＡ-K接口外螺纹内孔,长10mm,特征阻抗50Ω*注:DＣ电源接口和3。81接线端子供电均为12V，根据现场接线情况二选一即可。7．２外形设计图7．３结构外形尺寸图8实验方案序号试验项目名称试验样品数量试验结果试验单位1外观、重量、尺寸全检检验报告陕西卫峰2无线通信距离抽检测试报告陕西卫峰3无线通信速率抽检测试报告陕西卫峰4通信模块供电与功耗抽检测试报告陕西卫峰５通信基站功耗抽检测试报告陕西卫峰6一次工作时间抽检检验报告陕西卫峰772ｈ稳定性试验全检检验报告陕西卫峰８工作高温试验抽检检验报告陕西卫峰９工作低温试验抽检检验报告陕西卫峰１0工作湿度试验抽检检验报告陕西卫峰11贮存高温试验型式试验检验报告陕西卫峰12贮存低温试验型式试验检验报告陕西卫峰9项目进度和质量保证9．1项目研制进度计划序号名称时间备注1签订合同合同签订之日起算T０2质量计划1周T0+１3研制方案1周T0+1４研制方案评审１周Ｔ0+2５工程样机4周Ｔ０+66工程样机试验2周Ｔ0+8７设备制造6周T0+148试验大纲３周T0＋1４9型式试验2周T０＋16１0出厂验收２周Ｔ0＋189.2质量控制与文件交付进度计划文件清单如下:序号文件名称文件类型提交进度1技术文件、图纸１.1研制方案I合同签订后２周内1.2设备外形图、安装图、外部接线图I合同签订后2周内１。３通讯协议说明（LｏRa）Ｉ合同签订后2周内１.4安装说明书I合同签订后10周内2质保文件2.1产品出厂合格证明书Ｉ设备交运前１0主机与监测系统通信协议10。1概述本协议规定了主机与监测系统的通信协议，所有相关硬件设备都应遵从协议规范。10。２协议标准设置采用RS—４85标准接口。——标准协议：ModbusRTU协议。—-波特率：９600bps。—-设备地址：１－2４７（出厂默认值为０0Ｈ)。——通讯方式：监测主机主机主动发送命令，便携主机被动应答.１0．3字节格式编码系统：８位二进制，十六进制0‐9,A‐F。数据位：1起始位，8位数据（低位先送）,无奇偶校验,停止位1位.错误校验区:循环冗余校验（CRC16)

RTU错误校验码为2字节16位CRC码.10.４帧格式Ｍｏdbus信息以帧的方式传输,每帧有确定的起始点和结束点,使接收设备在信息的起点开始读地址，并确定要寻址的设备（广播时对全部设备)，以及信息传输的结束时间。RTU模式中，信息开始至少需要3。５个字节的静止时间，发送完最后一个字节后,也有一个3。5个字符的静止时间。整个信息必须连续发送。如果在发送帧信息期间,出现大于1．５个字符的静止时间时,则接收设备刷新不完整的信息,并假设下一个地址数据。开始地址功能数据校验终止T１—Ｔ2－T3-T４8biｔs8bｉtsＮ*8biｔs1６bitsT1—T2—Ｔ3－T410.5浮点数存贮和传输格式浮点数采用IEEE标准的单精度浮点数格式，如图所示，每个数由4字节组成，数据传输时,从第一字节到第四字节的顺序传送。10.６功能码功能代码功能名称０３(０x０3)读寄存器06（0x06)写单个寄存器1６（0x1０）写多个寄存器1０。7读写保持寄存器地址高字节低字节数据类型备注0０H实时数据ｆloat只读01H02H报警状态TF卡状态ucｈaｒ只读0３H电池电量uｃhａr只读０4H年月uchar读写05H日时ｕcｈar0６Ｈ分秒ucｈar0７H报警阈值ｆｌoａt读写０8H０9H报警时间uｃhａｒ读写0ＡH密钥设备编号ucｈar只限4８5接口0BＨ系统复位ucｈar只写02H、报警状态:0=正常，1=报警。TＦ卡状态：0＝正常，１=异常。03Ｈ、电量：0－10０.09H、报警时间：0=０．５s,1＝１s，2=2ｓ。0ＡH、设备编号:1—247。0BＨ、系统复位:写入０x00AＡ可复位。10.8举例1、读取设备数据与状态:0１030００0００0７xxxｘ(地址0１）地址功能码寄存器起始地址寄存器数量CRC01030０0０0007xxｘx从应答：０103０7０00０００50120701090C22xxxx地址功能码字节数实时数据（4字节)报警、TF卡０1０30E3Ｄ４ＣCCCD0００0电池电量时间CRC005012０701090C22xxｘx实时数据0。05Bq／cm2,未报警,ＴＦ卡正常，80％，18年7月1日9时12分34秒。２、读取报警时间:010300０900０1xxxx（地址01)地址功能码寄存器起始地址寄存器数量CRＣ0１03０0０９０001xxxx从应答：010３0２０00１ｘｘxx地址功能码字节数数据ＣRC0103020001xxxx报警时间为1s。写系统时间：01１00０0４000３１20701090C22xxｘx地址功能码起始地址寄存器数量数据CＲC0110000４０003120７０1090C22ｘｘｘx从应答:０10３０２0001xxxx地址功能码起始地址寄存器数量CＲC011000040003xxxx系统复位：０106000B00AＡxｘxx地址功能码寄存器起始地址数据CＲＣ０１0６000B00AAxxxx从应答:0１0６００0B０0AＡxxxx（成功原样返回)地址功能码寄存器起始地址数据CＲC０1０60０0B０0AAxxxx10。９异常响应出现异常指令时，设置功能码的MSＢ为1。这使得异常响应中的功能码值比正常响应中的功能码值高0x80，返回异常指令.地址功能码异常码CRC０18０｜xxｘxｘxxｘ异常码内容0１非法功能码02非法数据地址03非法数据10.10CRC16校验方式staticcｏnｓtuｉnt8auchCRCHi［］=｛0x0０,0ｘC1，0x81，0x４0,０x01，０xC0,０x80，0x41，０x01,0xC0,0x8０,0ｘ41,0x00，０xC1，０x8１，0ｘ40，0x01，0xＣ０，0ｘ8０，0x4１,0x00,０xC1,0x81,0x4０，0x00,０xＣ１，0x81，0x4０,0ｘ01,0xC0,０x80，0x41,0x01，０xC0,０x8０，0ｘ41，0x00，0ｘＣ１,０x８1,0x４０,0x00,0ｘC1，0x81，0ｘ40，0x0１，0ｘC0，0x８0，0x41,0x00,0xC1，0ｘ8１，0x4０，0x01,0xC0，０x80，0x41，０x01，０xC0,0ｘ80,０x41，０x00,0xＣ1,0x81，0x40，０x01,０xC0，0ｘ8０，0x４1,０x0０,0xＣ1，０x81，0x40,０x00，０xC1，0x81，0x4０,0ｘ01，0ｘC0,0x８0,0x4１，０x00，０ｘC1，0x８1,０x40，０x01,0xC0，０x80，0ｘ41，0ｘ０１，０xＣ0，0x80，0x４1，0x00，0ｘC１，０x8１,0x40，0ｘ00,０xC1，０x81，0x40,0x01，0xＣ0，0x８0，0x41，0ｘ０1，0xC0，０x８0，0x4１，0x0０,0xC1，0x81，0x40，0x0１，0xC０,０x８０，0x4１,0x00,０xC1，0x81,0x40，０ｘ００,０xC1,0x81,０x４0，0x01，0ｘC0，0x８０,０x41，0ｘ0１，0xC0，0x80，０x41，0x0０，０xC1,０ｘ81，0x4０,0x00，０xC１，０ｘ８1,０x4０，0ｘ01，0xC０，0x８0,０x41，０ｘ00，0xＣ1,0ｘ81，０x40，0x01，0xC0，０x80，0x４1，0ｘ01,0xC0,0ｘ8０,0ｘ41,0x00，0xＣ1，０x８1,0x40,0x00，0ｘC1,0ｘ81，0x４0，0x０1，0ｘC０,0x80，0x4１,0x01,０xＣ０，0x8０,0x41,0ｘ０0,0xC１,0ｘ81,0ｘ4０，0x01，0xC0，0x80，０ｘ41，0ｘ０0,０xC1,０x81,0x４０,0x00,0xＣ1，0ｘ８1，0x4０，0ｘ01，0xC0，0x８0，0x41,０ｘ0０，０xC１，０x81，0ｘ40，0x０1,0xC0,0ｘ80，0x４１，0x01,0xＣ0,０ｘ80，0x４1，０ｘ00,0xC1,０x81，0x4０，０x01，０xC0，0x80，０ｘ41，0x00,０xＣ1，0x８1,０ｘ40，0x０0,０ｘC1,0x81，0ｘ40,０ｘ01,0ｘC０,0x80，0x41,０x01，0xC０，0x80,0x4１,0x0０,0ｘＣ1,0x8１,０ｘ４0,0x00,0xC1，０ｘ81,0x４0，0x01,0xC0，0x80,0x４1，0x0０,０xC1，0x81,0ｘ40,0x0１，0xC０，0x８０,０ｘ41,0x01,0ｘC0,０x80,0ｘ41，0x００,０xC１,０ｘ81，０x４0}；stａtiｃｃｏnｓtuint8auchCRCLo［]=｛0x００，0xC0,0xC１，０ｘ01，0xC3,0ｘ03,0x０２,0ｘC2，０xC6，０ｘ06，0x０7,0xC7，０x0５，0xＣ5,０ｘC４，０x０4，０ｘCC,0x0C，0x0D,0xCD,0x0F,0ｘCF，0ｘCE，0x０Ｅ,0x0A,0xCA，0xCＢ，０x0B，0xC9,0ｘ09，0ｘ08，0ｘC8，0ｘD8,０x18，0x19,０ｘD９,0x1B,0ｘDB,0xDA，0ｘ1A，0x1Ｅ，0ｘDE,０xDF，0x1F,０xDD，0x1D，0ｘ１Ｃ，0xＤC,０x１4,0xＤ4，0xD5,0x15,0xＤ7,0x17，０x１6，0ｘD６,0ｘD2，0x1２，0x13，０xD３,0x11,0xD1，0ｘD0，0x10,0ｘF0,0x30,0x31,０ｘＦ1，0x3３，0ｘF3，0xF2,0x32，0x36,０xF6，0xF7，０ｘ37,０xＦ5,０x35,0x3４，０ｘF4，0ｘ3C，０xＦC，０xFD，0ｘ３D，０ｘFF，０x３F，0x３E,0xFE，0xFA,0x3A,０x３B,０ｘFB,0x３9，0xF9，０ｘF8，0ｘ３8，0x28，０xE８,０xE9,０x2９，0xEB,0ｘ2B,0x2Ａ，0xEＡ,0xEE,0x2E,0x2F，0xEＦ，0ｘ2Ｄ,0ｘED，０xEC,0x2C,０xE4,0x24，0x25，0xＥ5，0x２7，０ｘE７,0ｘE6，0x26，0x２2,０ｘE2，0xE3,0x23，０xE1，0x21，0x2０,0ｘE０，０ｘA0，0x６0,０x６1，０xＡ1，0x63，０xA3，0xA2，0x62，0x６6，０xA6,０xＡ７，0x6７，0ｘA5，0x65,0x6４，0xＡ4，0x６Ｃ,0xAC,0xAD，0x６D，0ｘAF，０x６Ｆ，0x6E，0xAE，０xＡA,０x6Ａ,0ｘ6Ｂ,0ｘAB,０x69，0xA9，0ｘA8，0x６8，０x78,０xB8，0xB9，0x７９,0xBＢ,0ｘ７B，0x7A，0xBA，0xBE，0x7E,０x7F,0xBF，0ｘ7D,０xBD，0xＢC，0x7C,0xＢ4，0x７4,0x7５，0xB5，0x77，0xB7,0ｘB６,０x76，0ｘ7２,0xB2,０xB3，0ｘ７3，0xB1，0ｘ71,０x70,０xＢ0,0ｘ50,0ｘ9０，0ｘ91,０x５1,0x93，0x5３,0x52,０x９2,0x96，0x56,0x5７，0x9７,0x５5，０x95,0x94，０x54,0ｘ9C,０x5C,0x5D，0ｘ9D，０x5F，0x9F，0x9E,0x5Ｅ，0ｘ５A，0x9A，0x9Ｂ,０x5B,0x99,０ｘ59,0x５8,０x98，0x８8，0x4８，０x49,0ｘ8９，0x4B,0x8B，０x8A,0ｘ4A，0x４E，0x8E，０x8F,0ｘ4F,０x8D,0x4Ｄ,0ｘ4C，０x８C,0x44,0x８4，0x85，0x４5,0x87,0x4７,0ｘ4６,0x86,0x82,0x4２，0x43，0x83，0x4１，０ｘ８1，0ｘ80,０x40｝；/＊＊＊＊＊＊**＊***＊*＊＊＊***＊＊＊＊*＊＊＊＊**＊＊＊＊**＊＊*＊＊*＊＊＊**＊＊＊*＊＊＊＊＊＊**＊*＊*Functｉonﻩ：ｃalculate_ｃrc*Dｅsｃriptｉｏn ：计算校验和*ＩｎputParａﻩ：＊OutputPａｒaﻩ：*ReturｎVaｌue：＊＊**＊＊＊＊＊**＊**＊**＊*＊＊＊＊*＊＊*****＊＊＊＊*＊＊*＊*＊＊＊*＊＊＊*＊＊*＊＊*＊＊**＊**＊/uｉnｔ16ｃalcｕlatｅ＿ｃrc（uiｎt8*ｐuchMsg,uint8ｕsDataLen){uiｎｔ8ucｈCRCHｉ=０xFF；uｉnt8ucｈCRCＬo=０xFＦ;uint8uIｎｄｅx；ﻩｕint１6CｒＣ16;whｉle（usDataＬｅn-—）｛ｕIｎdeｘ＝uchCＲCＨi^（*（pucｈMsg++）)；uchＣRCHi=ｕchCRCLo^ａuchＣRCHi[uIｎdex］；uchＣRCLo=ａuchＣRCLo[uIndeｘ］；} CrC１6=uｃhCＲＣＬo; CrＣ１6＜<＝8; ＣrC16+＝uchCRCHi；retｕrnＣrC16；｝微服务系统设计方案微服务本质 微服务架构从本质上说其实就是分布式架构,与其说是一种新架构，不如说是一种微服务架构风格。ﻩ简单来说,微服务架构风格是要开发一种由多个小服务组成的应用。每个服务运行于独立的进程，并且采用轻量级交互.多数情况下是一个HTTP的资源AＰI.这些服务具备独立业务能力并可以通过自动化部署方式独立部署。这种风格使最小化集中管理，从而可以使用多种不同的编程语言和数据存储技术。ﻩ对于微服务架构系统，由于其服务粒度小，模块化清晰，因此首先要做的是对系统整体进行功能、服务规划，优先考虑如何在交付过程中，从工程实践出发，组织好代码结构、配置、测试、部署、运维、监控的整个过程，从而有效体现微服务的独立性与可部署性。 本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。ﻩ理解微服务架构和理念是核心。系统环境名称版本说明ＪDK１。8SpringBoｏtＳprinｇＦrameｗｏrｋRibｂonkａfkaＲabｂiｔMQ微服务架构的挑战可靠性:由于采用远程调用的方式,任何一个节点、网络出现问题，都将使得服务调用失败，随着微服务数量的增多，潜在故障点也将增多。也就是没有充分的保障机制,则单点故障会大量增加.运维要求高: ﻩ系统监控、高可用性、自动化技术分布式复杂性：ﻩﻩ网络延迟、系统容错、分布式事务部署依赖性强:ﻩ 服务依赖、多版本问题性能(服务间通讯成本高）:ﻩ 无状态性、进程间调用、跨网络调用ﻩ数据一致性：ﻩ 分布式事务管理需要跨越多个节点来保证数据的瞬时一致性，因此比起传统的单体架构的事务,成本要高得多。另外，在分布式系统中,通常会考虑通过数据的最终一致性来解决数据瞬时一致带来的系统不可用。重复开发： ﻩ微服务理念崇尚每个微服务作为一个产品看待,有自己的团队开发，甚至可以有自己完全不同的技术、框架，那么与其他微服务团队的技术共享就产生了矛盾，重复开发的工作即产生了。ﻩ没有最好的，只有最适合自己的。架构设计思维设计ﻩ微服务架构设计的根本目的是实现价值交付，微服务架构只有遵循ＤevOps理念方可进行的更顺畅，思维方式的转变是最重要的。实现微服务技术架构，现有产品需要进行技术上的改进以及相关配套服务的实现，采用分阶段实施、以及试点产品优先实施的策略，主要包括如下：ﻩ一、技术上的改进:ﻩ1、前后端分离，web前端通过Hｔtｐ/Ｈttps协议调用微服务的APＩ网关，由AＰI网关再经过路由服务调用相应的微服务ﻩ２、不同微服务之间通过REＳT方式互相调用ﻩ3、微服务之间通过消息中间件实现消息交互机制ﻩ二、配套服务与功能实现: 1、需要进行相应的自动化服务实现，包括自动化构建、自动化安装部署、自动化测试、自动化平台发布(Ｄｏｃker实现）ﻩ2、管理服务，对于微服务架构，必须配套相应的监控与管理服务、日志管理服务等ﻩ３、协作服务,运用ＤeｖＯｐs思想提升开发、测试、运维的高效沟通与协作，实现开发与运维的一体化微服务架构设计ﻩ

１、我们把整个系统根据业务拆分成若干个子系统或微服务.

2、每个子系统可以部署多个应用,多个应用之间使用负载均衡。

３、需要一个服务注册中心Eureka，所有的服务都在注册中心注册，负载均衡也是通过在注册中心注册的服务来使用一定策略来实现。ﻩ Euｒeka可部署多个,进行高可用保证。

4、所有的客户端都通过同一个网关地址访问后台的服务，通过路由配置ZＵＵＬ网关来判断一个URL请求由哪个服务处理.请求转发到服务上的时候使用负载均衡Ribbｏｎ。

5、服务之间采用feigｎ进行调用.

6、使用断路器hyｓtrix,及时处理服务调用时的超时和错误，防止由于其中一个服务的问题而导致整体系统的瘫痪。

7、还需要一个监控功能，监控每个服务调用花费的时间等.8、使用SpringＣloudＣｏnfiｇ进行统一的配置管理，需要考虑与公司的配置管理平台如何配合使用。ﻩ９、Hyｓｔriｘ，监控和断路器.我们只需要在服务接口上添加Hｙsｔrix标签，就可以实现对这个接口的监控和断路器功能。

10、HystrixDａshboaｒd,监控面板，他提供了一个界面,可以监控各个服务上的服务调用所消耗的时间等。

11、Tｕrbiｎe，监控聚合，使用Hystｒｉx监控,我们需要打开每一个服务实例的监控信息来查看。而Tｕrbine可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。这样就不需要挨个打开一个个的页面一个个查看。架构的可靠性保证:ﻩ在关键节点做主备、集群部署,防止单点故障.待后续确认问题： １、AcｃessＣontrol：Zuｕl网关提供了相关控制功能，与我司ＣAS如何结合使用ﻩ2、ConｆigＳｅrver:ＳprinｇCloud提供了远程配置中心，与我司的配置管理平台如何结合使用设计阶段总体设计 1、功能规划：对产品功能进行拆分，拆分为若干个微服务；一个功能可以创建多个微服务并部署在多个服务器节点上,以便进行负载均衡。 2、设计原子服务层,梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层,逐渐形成稳定的服务中心,使应用能更快速的响应多变的客户需求。ﻩ3、为每个服务设计API接口(REST方式)ﻩ4、为不同的服务进行分类，不同类型的服务需要的资源不同，可以配置不同的资源,包括CＰU、内存、存储等。服务拆分原则ﻩ1、粒度微小: ﻩ根据业务功能划分服务粒度，总的原则是服务内部高内聚，服务之间低耦合。ﻩ2、责任单一： 每个服务只做一件事，即单一职责原则。 ３、隔离性原则： ﻩ每个服务相互隔离，且不互相影响ﻩ４、业务无关优先原则: ﻩ基础服务，是一些基础组件，与具体的业务无关。比如:短信服务、邮件服务.这里的服务最容易划分出来做微服务，也是我们第一优先级分离出来的服务。服务规划 为实现负载均衡，允许相同的服务在多个节点注册相同的服务名，不同的端口.如果没有前期的规划，不同的服务提供者可能会注册相同的服务名，导致消费者调用服务时产生调用混乱。ﻩ因此，需进行服务名的统一规划: 1、规划期统一制定每个服务提供者的服务名或者模块标示。ﻩ2、服务名的命名规则:ModuleＮaｍｅ_ＳeｒvｉｃeNamｅ，且所有字符小写，不同单词之间以下划线分隔。如用户管理模块提供了获取用户信息的服务,则命名为：useｒ_ｇｅｔ＿info。ﻩ3、新增服务名时，需要提出申请,审批通过后方可使用，为减少审批复杂度,可只审批ＭodｕleNａme,即在模块内部可以自由增加服务名,不需要进行审批。开发策略ﻩ总体原则：不同的微服务需进行物理隔离。ﻩ１、ＳVN策略：ＳＶN上创建独立的分支,不同微服务的代码提交不受相互影响; —-—由配置管理员统一控制。 问题:开发分支与集成分支,都将增加很多,维护工作量增加. 2、编译策略：代码编译时，各个微服务独立编译、打包,杜绝直接的依赖；ﻩ３、工程构建：代码开发时,各微服务创建独立的工程,工程之间不能产生直接依赖 ４、持续集成:每个微服务独立执行持续集成. 5、版本集成:由统一的集成工具，实现自动化的版本集成,将所有微服务集成到统一的版本发布包中。版本策略ﻩ每个微服务可以独立制作版本，伴随着服务的增多，SVＮ分支增多,版本也将增多，版本管理的复杂度将成指数级增加。在服务之间依赖较多时,每个服务的升级或降级都将影响其他服务的正常运行。 因此需执行如下策略： １、所有服务的版本制作交由专业的版本管理员执行. 2、采用自动化的版本制作策略，最大程度的减少人工操作.ﻩ３、每个服务的版本必须有详细的版本计划、版本说明,对于版本说明要制定模板，明确需要提交的内容、版本号、SVN标签等。ﻩ4、对项目经理的要求提升,需对整体的版本计划有严格的制定，尤其是版本之间的依赖关系要非常明确,版本升级、降级的风险评估需完全充分. ５、接口管理：严格执行接口管理制度,任何接口的变更必须进行审批、发公告等流程。数据库挑战与策略 每个微服务都有自己独立的数据库,那么后台管理的联合查询怎么处理？这应该是大家会普遍遇到的一个问题,有三种处理方案。ﻩ1）严格按照微服务的划分来做，微服务相互独立,各微服务数据库也独立，后台需要展示数据时，调用各微服务的接口来获取对应的数据，再进行数据处理后展示出来，这是标准的用法，也是最麻烦的用法。ﻩ2)将业务高度相关的表放到一个库中，将业务关系不是很紧密的表严格按照微服务模式来拆分,这样既可以使用微服务，也避免了数据库分散导致后台系统统计功能难以实现，是一个折中的方案。ﻩ3)数据库严格按照微服务的要求来切分，以满足业务高并发,实时或者准实时将各微服务数据库数据同步到ＮoSQＬ数据库中,在同步的过程中进行数据清洗，用来满足后台业务系统的使用，推荐使用MｏｎgｏDB、ＨＢａse等。 第一种方案适合业务较为简单的小公司；第二种方案,适合在原有系统之上，慢慢演化为微服务架构的公司；第三种适合大型高并发的互联网公司。ﻩ建议，我们当前采用第二种方案。负载均衡 不再采用一般的增加负载均衡服务器的方式进行负载均衡，如F５、Ngｉｎx、LVＳ等，而是把负载均衡的功能以库的方式集成到服务消费方的进程内,这种方案称为软负载均衡（SoｆｔLoaｄＢalａnｃｉng)或者客户端负载均衡.在SｐriｎgＣlｏuｄ中配合Euｒｅkａ的服务注册功能，Ribbon子项目则为RＥST客户端实现了负载均衡。ﻩ使用Ribｂｏｎ进行负载均衡，其工作原理可以概括为下面四个步骤:Ribbon首先根据其所在Zoｎe优先选择一个负载较少的ＥuｒekaSeｒｖer；定期从EurekａServer更新并过滤服务实例列表;根据指定的负载均衡策略,从可用的服务器列表中选择一个服务实例的地址;然后通过ReｓtClient进行服务调用。Ｒibbon本身提供了下面几种负载均衡策略:RoundＲobiｎRｕle:

轮询策略，Ｒiｂｂon以轮询的方式选择服务器,这个是默认值.所以示例中所启动的两个服务会被循环访问;RandomRule：

随机选择，也就是说Ribｂｏn会随机从服务器列表中选择一个进行访问;ＢeｓtＡvaiｌablｅRｕｌe：

最大可用策略,即先过滤出故障服务器后，选择一个当前并发请求数最小的；WeightedRespｏnｓeＴｉｍeRｕle:

带有加权的轮询策略，对各个服务器响应时间进行加权处理，然后在采用轮询的方式来获取相应的服务器;AvaｉｌabｉlityFｉlteringRulｅ：

可用过滤策略,先过滤出故障的或并发请求大于阈值一部分服务实例，然后再以线性轮询的方式从过滤后的实例清单中选出一个；ZonｅAvoidaｎceRule：

区域感知策略,先使用主过滤条件(区域负载器，选择最优区域)对所有实例过滤并返回过滤后的实例清单,依次使用次过滤条件列表中的过滤条件对主过滤条件的结果进行过滤，判断最小过滤数（默认1)和最小过滤百分比(默认0）,最后对满足条件的服务器则使用RｏｕnｄＲobinＲule（轮询方式）选择一个服务器实例。性能策略 １、网络优化:优化组网结构，提升网络间通讯性能; 2、配置优化：优化SpriｎgCloud组件集以及其他组件的配置信息，使得性能最大化.技术管理策略ﻩ微服务的架构理念中指出各微服务可以独立建设，可以使用不同的技术、语言、框架等，以便能更快速的使用新技术、新框架等响应特定客户需求，解决单体应用架构更新技术、更新框架时面临的困难或阻碍。ﻩ但这也同时带来了诸多问题，如下： 1、各服务是否可以任意使用自己的技术、自己的组件、框架呢？如果这样，势必带来更大的管理困难、维护困难、技术共享困难。 2、公共的方法如何实现共享？如格式化时间的一个简单方法需要共享，也需要封装为一个服务接口吗?ﻩ管理策略: 1、总体原则：仍然需要进行统筹考虑，所有组件统一管理,组件放置在产品仓库中，每个产品或服务需要共享组件时,从产品仓库获取。ﻩ2、特殊情况：特殊服务需要使用特殊的组件、框架,需提出申请，统筹规划后进行决策。开发阶段服务的调用AIP网关调用所有服务通过Zｕｕl网关进行调用,不允许直接调用微服务提供者。Ｚuul可能会成为系统瓶颈，在项目复杂时可考虑为Zｕul进行主备或负载均衡处理。同步调用ﻩ采用HTTＰREST方式进行调用，针对业务需求可以进行负载均衡，负载均衡的调用方式有两种：ﻩ1、FeｉgnClieｎt 2、RestＴｅｍplaｔｅﻩ建议使用ＦｅｉgnClienｔ方式进行服务调用。ﻩ不管是什么方式，他都是通过REＳT接口调用服务的http接口,参数和结果默认都是通过Ｊackson序列化和反序列化。因为ＳpｒingMVＣ的RestＣontrｏｌleｒ定义的接口，返回的数据都是通过Ｊackｓon序列化成JSON数据。异步调用ﻩrａbbitMq、kａｆka、SprinｇCｌouｄStream均是可以选择的方案.SprｉngClｏｕｄStreａm，基于Redis、Rabbit、Kafkａ实现的消息微服务,简单声明模型用以在SprinｇCloud应用中收发消息。服务间调用的权限验证一般我们的API接口都需要某种授权才能访问,登陆成功以后，然后通过ｔokｅn或者ｃoｏkie等方式才能调用接口。使用ＳpringCloudＮetｆix框架的话,登录的时候,把登录请求转发到相应的用户服务上,登陆成功后，会设置ｃookie或headertoｋeｎ等。然后客户端接下来的请求就会带着这些验证信息，从Zuｕl网关传到相应的服务上进行验证。Zuｕl网关在把请求转发到后台的服务的时候，会默认把一些heａder传到服务端，如：Cｏｏkie、Seｔ－Ｃookiｅ、Authorizatｉｏn.这样,客户端请求的相关headerｓ就可以传递到服务端，服务端设置的coｏkie也可以传到客户端。但是，如果你想禁止某些heaｄer透传到服务端，可以在Zｕul网关的aｐpｌiｃation.yml配置里通过下面的方式禁用:zuul:ﻫroutes:ﻫusers：

ｐaｔh：／users／*＊

ｓensiｔｉveHｅａders：Coｏkｉe,Sｅt—Coｏkｉe，Authoｒｉｚaｔion

s