服务，运用DevOps思想提升开发、测试、运维的高效沟通与协作，实现开发与运维的一体化
22系统架构设计
架构图1

f
1、我们把整个系统根据业务拆分成若干个子系统或微服务。2、每个子系统可以部署多个应用，多个应用之间使用负载均衡。3、需要一个服务注册中心Eureka，所有的服务都在注册中心注册，负载均衡也是通过在注册中心注册的服务来使用一定策略来实现。Eureka可部署多个，进行高可用保证。4、所有的客户端都通过同一个网关地址访问后台的服务，通过路由配置ZUUL网关来判断一个URL请求由哪个服务处理。请求转发到服务上的时候使用负载均衡Ribbo
。5、服务之间采用feig
进行调用。6、使用断路器hystrix，及时处理服务调用时的超时和错误，防止由于其中一个服务的问题而导致整体系统的瘫痪。7、还需要一个监控功能，监控每个服务调用花费的时间等。8、使用Spri
gCloudCo
fig进行统一的配置管理，需要考虑与高管局现有的spri
gCloud平台的配置管理平台如何配合使用。9、Hystrix，监控和断路器。需要在服务接口上添加Hystrix标签，就可以实现对这个接口的监控和断路器功能。10、HystrixDashboard，监控面板，提供了一个界面，可以监控各个服务上的服务调用所消耗的时间等。11、Turbi
e，监控聚合，使用Hystrix监控，我们需要打开每一个服务实例的监控信息来查看。而Turbi
e可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。这样就不需要挨个打开一个个的页面一个个查看。架构的可靠性保证：在关键节点做主备、集群部署，防止单点故障。
待后续确认问题：
1、AccessCo
trol：Zuul网关提供了相关控制功能，高管局现有的spri
gCloud与系统的

f
CAS如何结合使用2、Co
figServer：Spri
gCloud提供了远程配置中心，高管局现有的spri
gCloud与系统
的的配置管理平台如何结合使用
3设计阶段
31总体设计
1、功能规划：对产品功能进行拆分，拆分为若干个微服务；一个功能可以创建多个微服务并部署在多个服务器节点上，以便进行负载均衡。
2、设计原子服务层，梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使应用能更快速的响应多变的客户需求。
3、为每个服务设计API接口（REST方式）4、为不同的服务进行分类，不同类型的服务需要的资源不同，可以配置不同的资源，包括CPU、内存、存储等。

f
各项目工程公司
工程处展示平台
其他业务系统1…其他业务系统N
ZUUL网关路由
ZUUL网关路由
系统业务服务
系统通用服务
r