转载

《提升能力,涨薪可待》-如何设计一个符合自己公司的微服务架构

使用微服务架构可以为我们带了好处、便利的同时,但也带了很多挑战,新的问题。比如,微服务之间的调用和调用和通信会不会很复杂? 通讯模式,一对一还是一对多的?依赖的服务没有准备好,如何验证我的开发功能?数据一致性的问题等等。 总结起来:

  • 微服务的粗细粒度难于掌握
  • 分布式的微服务增加了服务之间互相调用以及通信的复杂性
  • 数据一致性问题
  • 测试复杂度提升,微服务集成关联
  • 运维复杂度陡增,部署数量多、监控进程导致整体运维复杂度提升
  • 依赖服务变更难于跟踪

为了解决这些问题,我们在设计微服务架构时,必须进行全盘考虑,权衡利弊,这样才能做出合理的抉择,达到最佳的效果,从而达到我们复杂系统微服务拆分的最终目的。接下来我们来讨论讨论设计思想。

2. 微服务划分方法

微服务架构设计首要任务根据给定的因素粗粒度将业务功能合理的划分微服务。每个公司每个复杂系统业务划分区域都不同,但都可以基于这两种方式创建微服务:

  • 按照业务功能不同水平划分-Rest API微服务:
    • 负责业务功能行为设计
    • 数据管理
    • 基于Rest协议对外提供接口
  • 基于Rest API微服务前后端分离垂直划分-Web UI微服务:
    • 专注于交互页面的设计
    • 基于Rest API微服务存取数据

基于分布式的高性能、高并发的设计,结合Rest API微服务和Web UI微服务可以构建一个适应任何规模访问的多维的稳定牢固,且扩展性良好的系统平台。

3. 微服务治理与统筹

在微服务设计中,微服务治理能力是至关重要的,甚至一个微服务系统好坏,取决微服务治理能力。可以使用治理组件和服务来管理统筹庞大分布式系统,确保系统处于有序不乱、稳定而高效。

这里只提供Spring Cloud基础组件(选择治理组件应该基于公司的情况而定),包括:

  • Eureka(微服务注册与发现):提供服务注册和发现的功能。
  • Ribbon(负载均衡):提供负载均衡调度管理的功能。
  • Zuul(微服务网关):提供网关服务和动态路由的功能。
  • Hystrix(微服务熔断):提供容错机制、服务降级、故障转移等功能。
  • Config(统一配置):提供统一的配置管理服务功能。
  • Sleuth(微服务跟踪):可用来监控集群中服务运行情况。

这些组件是如何进行微服务治理的呢?主要过程如下图:

《提升能力,涨薪可待》-如何设计一个符合自己公司的微服务架构

4. 水平方向-Rest API微服务设计

Rest API微服务实现功能:

  • 负责业务功能行为设计
  • 数据管理
  • 基于Rest协议对外提供接口

Rest API微服务主要是关于涉及数据库,其中,数据管理基于数据库实现数据持久化。接口开发根据Restful规范使用GET、POST、PUT、DELETE对数据进行CRUD操作。

但最重要的如何设计Rest API微服务,其性能将对整个系统的性能至关重要,起决定性作用。这边提供一下方案:

  • 使用数据库集群和分组提供数据库访问性能:

    • 基于分布式架构集群,通过主从同步方式扩展数据库访问性能,多个只读从机缓解主机读写压力
    • 基于集群分组, 通常情况下,只有一个分组正常服务,其他作备份角色。
  • 数据库中间件实现读写分离

  • 使用数据缓存也是可以提搞数据存取性能,可使用Redis等高性能的NoSQL数据库。但为了提供缓存的命中率,需遵守:

    • 不要在缓存中存取大容量的数据
    • 合理设置每个缓存数据的有效时间,不将缓存数据做持久化。
  • 保持Rest API微服务的独立性,禁止在Rest API微服务中之间进行互相调用。

5. 垂直方向-Web UI微服务设计

基于Rest API微服务前后端分离的垂直划分-Web UI微服务包括两个功能:

  • 专注于交互页面的设计
  • 基于Rest API微服务存取数据

在设计Web UI微服务主要考虑是高并发的问题,可以通过以下方法来实现高并发:

  • 在Rest API微服务,使用FeignClient实现负载均衡调用。FeignClient自动实现了Zuul动态路由和Ribbon负载均衡服务

  • 使用Hystrix组件实现断路器的设计,提供对服务访问容错设计和降级使用机制。

  • 使用非阻塞的异步调用实现高并发

  • 使用分布式文件系统,将图片、视频等资料独立一个分布式文件系统管理。比如,FastDFS。

6. 微服务之间调用规则

为了保证各个微服务的独立性,并减少通信的复杂性,提高微服务之间的调用效率,我们对微服务之间的调用,遵循如下规定:

  • 服务之间主要有 Web UI微服务对Rest API微服务调用 ,一个Web UI微服务可以并发调多个Rest API。
  • 为了保证Rest API的高性能特性,同时避免Rest API变更影响,禁止Rest API之间互相调用, Rest API之间只能通过MQ进行互相通信
  • Web UI之间可使用与之对应的实例进行相互跳转,还可以进行负载均衡管理。

7. 数据最终一致性设计

对于微服务的多服务架构数据需确保数据一致性,可以基于CAP原理的BASE理论来合理设计。具体实现操作:

  • 通过调用各个Rest API实现实时同步操作
  • 使用消息通道以事件响应的方式进行异步处理。

CAP(Consistency,Availability,Partition tolerance)即一致性、可用性、分区容错性三者不可兼得

BASE(Basically Avaiable,Soft state,Eventually consistent)即基本可用、软状态、最终一致性。BASE是对CAP中一致性和可用性进行权衡的结果

原文  https://juejin.im/post/5dd0d398f265da0bd315cc4c
正文到此结束
Loading...