微服务架构设计

Posted 2021-04-14 中生代架构

架构师成长的好伙伴

连接技术 接力价值

 第45篇架构好文：2953字 | 6分钟阅读

摘要

微服务设计不应是一个讲求标准答案, 简单粗暴的设计过程。而应该是一个考量各方因素下的一个决策的过程。所谓的微服务具体应包含哪些核心的概念?既有的架构迁移到微服务的又有哪些策略？

01

微服务架构的核心概念

_____

微服务设计是架构设计。

所以, 微服务设计不应是一个讲求标准答案, 简单粗暴的设计过程。而应该是一个考量各方因素下的一个决策的过程。

所以, 在探讨微服务设计前, 我们先来探讨下, 所谓的微服务具体应包含哪些核心的概念?

I. 分布式 (Distributed):

微服务与微服务间分布式调用最主要的概念便是:

protocol-aware heterogeneous interoperability; 

各微服务可各自拥有自身的 platform (Java,C＃, Scala…等等), 但, 各微服务间却只能藉由单一共同的协议 (protocol); 如: REST; 进行分布式的调用。

II. 分别部署 (Separately Deploy):

微服务架构的产品或许会有数百甚至数千个微服务所构成。所以, 部署微服务时, 便很难经由手工来完成, 而必须相当程度的依赖自动化的 DevOps 工具。

III. 服务组件 (Service Component):

微服务是以服务组件, 而不是以类或模块的方式体现; 每个服务组件会包含一个或多个类或组件。

微服务共分为两大类:

A.  Infrastructure Services: 主要是为产品中其他的微服务提供服务; 被产品中其他的微服务直接的调用。

如: login service 便是一Infrastructure Services 的例子; 主要是为产品中其他的微服务提供产品登入的服务。

所以, Infrastructure Services 对产品外部的使用者界面、系统、设备都是不可见的, 也就是说, 产品外部的使用者界面、系统、设备是无法经由 api layer 来找到 Infrastructure Services 的。

B.  Functional Services: 主要是为产品外部的使用者界面、系统、设备提供某一端到端业务场景的服务。

所以, 相对于 Infrastructure Services, 

Functional Services 对产品外部的使用者界面、系统、设备而言, 都是可见的。也就是说, 产品外部的使用者界面、系统、设备是经由 api layer 来找到 Functional Services 的。

IV. 边界上下文 (Bounded Context):

微服务的边界上下文包含:

A.  某一端到端业务场景 (功能) 。

B.  数据 (数据库) 。

微服务的边界上下文, 使得每一个微服务拥有各自的某一端到端业务场景 (功能)与数据 (数据库) 。

更重要的是: 当微服务X需调用微服务Y, 则微服务X 与微服务Y的边界上下文, 将可避免或降低发生, 当微服务Y 运作失败时, 会影响到微服务 X。

所以, 微服务的边界上下文提供了一个很重要的微服务概念：微服务应能独立各自的开发、测试, 并且当发布、部署后, 亦不致影响到其他微服务的功能或运作。

V. 不共享任何事物 (Share Nothing):

因为, 微服务间共享任何的事物, 将会造成微服务间的依赖。

所以, 微服务间应避免共享任何的事物; 如:继承结构下的抽象接口, 服务, 模块, utility, 类, 数据 (数据库)…等等。

VI. api layer:

api layer 主要是在微服务与微服务外部的使用者界面、系统或设备之间构建:

A. endpoint proxy: 隐藏各微服务的endpoint。

当某个新增的场景在某个新的微服务上开发完后, 这个新的微服务便会有了新的 endpoint。 而api layer 便可将此微服务外部的使用者界面、系统或设备导向此新的微服务上的 endpoint。

使得微服务外部的使用者界面、系统或设备可在不需要有任何修改的情况下, 便可以使用此新的微服务。

而当微服务外部的使用者界面、系统或设备发现此新的微服务不适用时, api layer 便可将微服务外部的使用者界面、系统或设备导向旧的微服务上的 endpoint, 而使得新的微服务, 对微服务外部的使用者界面、系统或设备而言, 变得不可见。

B. load balancer: 多节点间的负载均衡。

VII. 开发新的微服务优于在既有的微服务上不断的加新的场景或功能:

当某个微服务开发完后, 便应避免不要再在此微服务上, 不断的加新的场景或功能; 新的场景或功能应该是属于另一个新的微服务。

02

从既有的架构迁移到微服务的策略

_____

在微服务的核心概念中, 最重要的核心概念便是: 边界上下文 (Bounded Context); 每一个微服务拥有各自的某一端到端业务场景 (功能)与数据 (数据库) 。

当将既有的架构迁移到微服务时, 常见的作法便是:

A.  只将既有架构的功能模块拆解成粒度较小的功能模块:

这样的作法, 其实, 实质上的意义是不大的。因为, 即使拆解成粒度较小的功能模块, 并且拆解后的各功能模块能互相的解藕, 但, 拆解后的各功能模块, 也许仍需共用数据库。

所以, 当数据库即使只是修改某个数据表结构的某几个字段时, 也需同时修改多个功能模块。毫无疑问的, 这不仅会使产品开发的效率低落。拆解后的各功能模块, 在执行持续部署时, 将会有极大的概率会在某个阶段中断。同时, 也会为产品的架构引入新的风险, 甚至是致命的伤害。

B.  将既有架构的功能模块拆解成粒度较小的功能模块的同时, 也将既有数据库拆解; 使拆解后的各功能模块, 在拆解后, 便可拥有各自的数据库:

这样的作法, 所会带来的最大的问题是: 日后, 不论是发现拆解后的各功能模块, 粒度是过小或过大, 而需合并或再拆解功能模块时, 都将会有极大的概率, 会花费相当大的工作量在数据库的迁移上。

在将既有的架构迁移到微服务时, 架构师必需要考虑下列两个因素:

1. 我们其实是没法在一开始的时候、一步到位, 就能设计出正确、适当的微服务粒度的; 正确、适当的微服务粒度, 绝对是要经由不断的演进与学习而获得的。

2. 数据库的迁移风险极大; 一定要谋定而后动。

所以, 从既有的架构迁移到微服务的策略是：

I. 先以产品架构的性能、可靠性与安全性为首要的考量; 先拆解出粒度大的功能模块。

II. 再考量持续部署的独立性与对业务应变的能力, 而将必要的功能模块再拆解成粒度较小的功能模块。

III. 确定了所拆解的功能模块是正确、适当的微服务粒度后; 同时兼顾了性能、可靠性、安全性、持续部署的独立性与对业务应变的能力; 再进行数据库的拆解与迁移; 使各功能模块 (微服务) 真正拥有各自的数据库。最终, 使各功能模块 (微服务) 真正拥有正确、适当的边界上下文 (Bounded Context) 。

架构师应一直铭记在心:

微服务正确、适当的边界上下文 (Bounded Context), 绝对是要经由不断的演进与学习而获得的; 没有标准答案, 没有一步到位的。

想要加入中生代架构群的小伙伴，请添加群助手小姜的微信

申请备注（姓名+公司+技术方向）才能通过哦！

突破是中生代社区新上架的图书，签名版仅在送礼神器销售，限300本，先到先得

推荐阅读