微服基于springcloud微服务系统设计方案

微服务系统设计方案

1 .微服务本质

微服务架构从本质上说其实就是分布式架构, 与其说是一种新架构, 不如说是一种微服简单来说 微服务架构风格是要开发一种由 多个小服务组成 的应用 每个服务运行于独立的进程并且采用轻量级交互 。多数情况下是一个HTTP的资" 原API。这些服务具备独立业务能力并可以通过自动化部署方 K独立部署。这种风格使最小化集中管理从而可以使用多种

不同的编程语言和数据存储技术

对于微服务架构系统, 其服务粒度小 模块化清晰, 因此首先要做的是对系 统整体进行功能、服务规划优先考虑妇何在交付过程中从 工程实践出 发组织好代码结构、配置、、测试、部署、运维、监控 的整个仙程从而有效体现微服务的独立性与, 可部署性。

;亍综合阐

务架构风格。

本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进;

理解微服务架构和理念是核心。

2.系统环境

RabbitMQ

3.微服务架构的挑战

可靠性

由于采用远程调用的方式 任何一个节点、 网络出现问题 都将使得服务调用失败

随着微服务数量的增多潜在故障点也将增多。

也就是没有充分的保障机制则单点故障会大量增加。

运维要求高

系统监控、高可用性、 自动化技术

分布式复杂性

网络延迟、系统容错、分布式事务

部署依赖性强

服务依赖、多版本问题

性能服务间通讯成本高 

无状态性、进程间调用、跨网络调用

数据一致性

分布式事务管理需要跨越多个节点来保证数据的瞬时一致性 因此比起传统的单体架构的事务成本要高得多。另外 在分布式系统中通常会考虑通过数据的最终一致性来解决数据瞬时一致带来的系统不可用。

重复开发

微服务理念崇尚每个微服务作为一个产品看待 有自己的团队开发 甚至可以有白己完全不同的技术、 框架那么与其他微服务团队的技术共享就产生了矛盾 重复开发的工作即产生了。

4.架构设计

4.1 .思维设计

微服务架构设计的根本目的是实现价值交付 微服务架构只有遵循DevO ps理念方可进行的

更顺畅思维方式的转变是最重要的。

实现微服务技术架构 现有产品需要进行技术上的改进以及相关配套服务的实现, 采用分阶

段实施、 以及试点广品优先实施的策略

1 、前^酬分离 web前端通过 API网―

2、不同微服务之间通过 REST方式互相调用

3、微服务之间通过消息中间件实现消息交互机制____________________________

一、配套服务与功能实现  「 I ]

1 、 需要进行相应的自动化服』实现 包括自动化构建、 自动化Z装部署、 自动化测试、自动化平台发布Docker

2、 管理服务对寸微服务架』 必须配套相应的监控与管4^ 日志理服务卜

3、 协作血务运卜DevOps试、运伽高#沟通与协作实现开发与七维的一体化

4.2.砌g构设计

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

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

3、需要一个服务注册中心 E u re ka,所有的服务都在注册中心注册 负载均衡也是通

过在注册中心注册的服务来使用一定策略来实现。

E u re ka可部署多个进行高可用保证。

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

5、 服务之间采用 feign进行调用。

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

7、 还需要一个监控功能监控每个服务调用花费的时间等。

8、使用SpringCloud Config进行统一的配置管理需要考虑与公司的配置管理平台如何配合使用。

9、 Hystrix监控和断路器。我们只需要在服务接口上添加 Hystrix标签就可以实现对这个接口的监控和断路器功能。

10、 Hystrix Dashboard,监控面板他提供了一个界面可以监控各个服务上的服务调用所消耗的时间等。

1 1 、 Turbine监控聚台使用Hystrix监控我们需要打开每一个服务实例的监控信息来查看。而Turbine可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。

这样就不需要挨个打开一个个的页面一个个查看。

架构的可靠性保证

在关键节点做主备、集群部署防止单点故障。

待后续确认问题

1 、Access Control :Zuul网关提供了相关控制功能与我司 CAS如何结合使用

2、Config Server :Spring Cloud提供了远程配置中心与我司的配置管理平台如何结合使用

5.设计阶段

5.1 .总体设计

1 、功能规划对产品功能进行拆分拆分为若干个微服务一个功能可以创建多个微服务并部署在多个服务器节点上以便进行负载均衡。

2、 设计原子服务层梳理和抽取核心应用、公共应用作为独立的服务下沉到核心和公共能力层逐渐形成稳定的服务中心使应用能更快速的响应多变的客户需求。

3、 为每个服务设计API接口 REST方式

4、 为不同的服务进行分类不同类型的服务需要的资源不同可以配置不同的资源 包括CPU、 内存、存储等。

5.2.服务拆分原则

1 、 粒度微小

根据业务功能划分服务粒度 总的原则是服务内部高内聚服务之间低耦台。

2、 责任单一:

每个服务只做一件事 即单一职责原则。

3、 隔离性原则

每个服务相互隔离且不互相影响

4、 业务无关优先原则

基础服务是一些基础组件与具体的业务无关。 比如短信服务、邮件服务。这里的服务最容易划分出来做微服务也是我们第一优先级分离出来的服务。

5.3.服务规划

为实现负载均衡 允许相同的服务在多个节点注册相同的服务名 不同的端口。 如果没有前期的规划 不同的服务提供者可能会注册相同的服务名 导致消费者调用服务时产生调用混乱。

因此需进行服务名的统一规划

1 、规划期统一制定每个服务提供者的服务名或者模块标示。

2、服务名的命名规则  ModuleName_ServiceName 且所有字符小写 不同单词之间以下划线分隔。如用户管理模块提供了获取用户信息的服务则命名为 user_get_info。

3、新增服务名时需要提出申请 审批通过后方可使用为减少审批复杂度可只审

批ModuleName 即在模块内部可以自由增加服务名不需要进行审批。

5.4.开发策略

总体原则不同的微服务需进行 物理隔离。

1 、 SVN策略 SVN上创建独立的分支不同微服务的代码提交不受相互影响

---由配置管理员统一控制。

问题开发分支与集成分支都将增加很多维护工作量增加。

2、 编译策略代码编译时各个微服务独立编译、打包 杜绝直接的依赖

3、 工程构建代码开发时各微服务 创建独立的工程 工程之间不能产生直接依赖

4、 持续集成每个微服务 独立执行持续集成 。

5、 版本集成 由统一的集成工具实现自动化的版本集成将所有微服务集成到统一的版本发布包中。

5.5.版本策略

每个微服务可以独立制作版本伴随着服务的增多 SVN分支增多版本也将增多版本管理的复杂度将成指数级增加。 在服务之间依赖较多时 每个服务的升级或降级都将影响其他服务的正常运行。

因此需执行如下策略

1 、 所有服务的版本制作交由专业的版本管理员执行。

2、 采用自动化的版本制作策略最大程度的减少人工操作。

3、 每个服务的版本必须有详细的版本计划、版本说明对于版本说明要制定模板 明

确需要提交的内容、版本号、 SVN标签等。

4、 对项目经理的要求提升需对整体的版本计划有严格的制定尤其是版本之间的依

赖关系要非常明确版本升级、降级的 风险评估需完全充分。

5、 接口管理 严格执行接口管理制度 任何接口的变更必须进行审批、 发公告等流程。