Cloud-Native 微服务架构元素卡; 15 分钟内搞定微服务架构设计

I.前言:

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

但是, 这种决策的过程, 按照传统架构设计的方法, 往往会相当的耗时; 是不大容易能 “高效” 的做得到位的。

主要的原因是:

微服务太复杂了…

1.每个版本会有数个到数十个微服务需进行架构设计。

2.每个微服务均需考量多个架构上的因素; 如: 微服务间如何维持数据的一致性? 如何获得彼此间的数据? 彼此间数据交换的格式? 等等。

3.每个版本的数个到数十个的微服务, 会有一个到多个的团队在同时进行架构设计。

所以, 在 Cloud-Native 微服务的世界里, 我们需要有一个全新、可视化、轻量级的­架构设计方法; 使得多个团队、多个微服务可在 15 分钟内, 就完成 Cloud-Native 微服务架构设计。

II.本文:

Cloud-Native 微服务架构元素卡; 积累了业界与多个项目的经验, 将Cloud-Native 微服务架构设计需要考量的要素, 归纳、整理成 “卡片”。使得多个团队的开发人员、测试人员、产品管理人员可高效的协作、分析、设计出最适合每个微服务的架构方案。

[图一：微服务架构元素卡]

如图一所示: 微服务架构元素卡, 将 Cloud-Native 微服务架构设计所需考量的要素分成为五大类; 整合、保护、报表、共享、数据共享; 共 15 张 “卡片”。

[图二: 团队的开发人员、测试人员、产品管理人员共同协作, 进行 Cloud-Native 微服务架构设计]

[图三: 团队根据各个微服务的场景, 由 “微服务架构元素卡” 中选取最适合的架构方案]

如图二、图三所示: 团队的开发人员、测试人员、产品管理人员运用 “Cloud-Native 产品级敏捷 2.0” 分析、设计出各个微服务的边界、场景, 然后, 再利用 “微服务架构元素卡” 在 15 分钟内, 为每个微服务选取最适合的架构方案。

微服务架构元素卡说明如下：

1.整合: 合约变换

合约变换 (contract transformation) 有两种作法:

u由另一个微服务 Y 专注将合约变换 (contract transformation) 做到最好。当整个产品中, 多数的微服务都需合约变换 (contract transformation) 时, 便需采用此方案。

u在既有微服务 X 新增一的 endpoint, 处理合约变换 (contract transformation) 。当采用此方案时, 需注意原微服务 X 是否会因为新增此合约变换 (contract transformation), 而变的过于复杂。

2.整合: Gateway

这种架构上的作法, 也可应用在既有系统, 还没法转移到微服务的架构时; 可针对每一个对既有系统的调用, 先开发一个 Microservice Gateway。然后, 再逐步将既有系统的功能、场景转移到相对应的 Microservice Gateway 中。如此, 当既有系统的功能、场景转移到相对应的 Microservice Gateway 中后, 也不必再重新修改, 原先会调用 Microservice Gateway 的外部的使用者界面、系统、设备或是微服务。

3.保护: Circuit Breaker

当在微服务的 Client 与微服务间置入 Circuit Breaker 后, 微服务外部 Client 远程调用的 Time Out 时间便是:

微服务 Client 远程调用 Circuit Breaker 的时间 + Circuit Breaker 送回信息到微服务外部 Client 的时间。

而这所需的时间便相当的短, 也许只需 1~2 ms。

所以, Circuit Breaker 在整体微服务架构下, 扮演著相当重要的角色; 不仅保障了微服务整体的可靠性, 更不至于因保障了微服务整体的可靠性, 而牺牲了微服务整体的性能。

4.报表: Database Pull

此设计方案主要需注意的是: 破坏了原微服务的边界上下文 (Bounded Context), 使得原微服务无法独立自主的修改自身所拥有的数据表结构; 原微服务若有任何数据表结构上的修改, 将会影响到生成报表的服务所拥有的数据库。

5.报表: HTTP Pull

此设计方案主要需注意的地方是:

l性能上的问题: 当负责生成报表的微服务需同时向许多个 (上百个) 微服务获取数据时, 则就表示将会有上百个远程调用会发生。所以, 有可能负责生成报表的微服务的某一个数据请求, 已经达到了 Time Out, 但有的微服务所提供的数据, 还尚未送至负责生成报表的微服务。

l数据量的问题: 当负责生成报表的微服务向其它的微服务获取大量的数据时; 例如: 整个月的股票买卖。则大量的数据将造成大量流量, 所以, 也有可能对负责生成报表的微服务的某一个数据请求, 造成 Time Out。

6.报表: Batch Pull Upload

此设计方案因为同样是属于 Shared Data Integration Style, 所以, 需注意: 破坏了原微服务的边界上下文 (Bounded Context) 的问题; 使得原微服务无法独立自主的修改自身所拥有的数据表结构。原微服务若有任何数据表结构上的修改, 将会影响到生成报表的服务所拥有的数据库。

当然, 此设计方案的另一个需注意的地方便是: 数据的时效性; 生成报表的微服务所拥有的数据库, 将无法获得实时的各微服务所拥有的数据库中的数据。

7.报表: Event-Based Push

此设计方案不仅维持了各微服务的边界上下文 (Bounded Context), 更使得生成报表的服务所拥有的数据库或数据仓储, 获得实时的各微服务所拥有的数据库中的数据; 拥有数据的时效性。但, 开发实现的难度也相对较高。因为, 生成报表的微服务必需知道: 针对每一个微服务所拥有的数据库发生变更时所产生的事件, 要如何做出相对应的动作, 以维护其所拥有的数据库的数据的时效性; 这确实不是件容易的事。

8.共享: Compile Binding

此种方案, 从开发的角度, 其好处是显而易见的: 不需重启运维中的微服务, 而是在编译, 单元测试的时候, 特定的微服务便可立即知道, 在共享工程中的任何的修改或变更, 对微服务自身的影响为何? 然而, Compile Binding 却存在著个严重的问题: 当共享的工程与数十个、上百个微服务是 Compile Binding 时, 则有的微服务可编译, 可测试通过, 可发布、有的微服务却发生了无法编译, 或测试不通过、有的微服务则发生了无法发布....; 真的是一场灾难。更糟糕的是, 当灾难发生时, 各个微服务也没法对所共享的工程, 有任何的选择权或控制权; 各个微服务无法选择自身所要的共享工程的版本。

9.共享: Shared Library

此方案最大的好处便是: 各个微服务间对其所共享的 Shared Library拥有所谓的选择权; 也就是说, 某个微服务可选择 1.0 版的 JAR, 另一个微服务则可以选择 1.5 版的 JAR。当然, 缺点是: 当有数十个、上百个, 甚至是上千个微服务共享某个发生变更的 Shared Library时, 则这些为数众多的微服务便得一一的重新启动后, 才能执行测试, 才能得知 Shared Library 的改变, 对各个微服务的影响。

Share Library 应尽量的能细分到某一特殊功能的粒度; 如: 某一庞大的 Backend.jar 应细分为Persistence.jar, SQL.jar, Security.jar。某一大而全的 Utility.jar 亦应细分为Calculator.jar, MaxTime.jar。这样的细分粒度, 将有利于能更精确的分析出, Shared Library在每个版本中到底变更些了什么? 各微服务针对这些变更, 所应采取的相对应的措施为何?

10.共享: Replication

此方案虽然违背了 DRY (Do not Repeat Yourself.), 但却使得每个微服务维持了自身的边界上下文 (Bounded Context), 而使得产品中的数百个或甚至数千个微服务间的依赖降低; 产品中的数百个或甚至数千个微服务间的依赖越少, 各微服务便得以更高效的方式进行开发、测试、发布。

当然, 必需要确保: Copy-Paste 到各个微服务中的模块 (代码) 的质量是稳定的与变更的频率是不高的。因为, 任何一个质量上的缺陷或任意的变更, 将会造成数百个或甚至数千个微服务维护的工作量。

11.共享: Service Consolidation

当某个Shared Library; 如: 某个.jar; 被多个微服务所共用时, 则当此 Shared Library 有变更时, 多个共用此 Shared Library 的微服务, 将必需再次的被测试, 再次的被发布。

此时应重新的思考: 这些共用 Shared Library 的微服务, 那些或全部可与 Shared Library 合并为一单一的微服务; 合并后, 将可减化 Shared Library 变更后的测试与发布的复杂度与工作量。

12.数据一致性: Batch Data Sync.

采用此方案时, 必需先行确认: 未维持数据一致性的微服务; customer wish list微服务与 customer preference 微服务; 是可以接受从 Soft State 到 Eventual Consistency, 需经过一段较长的时间的; 也许是一天, 甚至是更久。

另外, 在采用此方案时, 也应该清楚的知道: 此设计方案将使得各微服务间的数据库, 因为, 批次处理而形成了“藕合”。

藕合”就代表著, 有任何一个微服务在数据库表节构上的任何的变更, 都将会造成批次处理代码 (脚本) 维护上的工作量; 假如, 某一个产品拥有上百或上千个微服务时, 则批次处理代码 (脚本) 维护的工作量, 往往会是一不小的负担。

13.数据一致性: Periodic Data Sync.

此设计方案, 虽缩短了从 Soft State 到 Eventual Consistency, 所需经过的时间, 但, 也是如 Batch Data Synchronization 有著一样需注意的地方: 各微服务间的数据库, 因为, 批处理而形成了“藕合”。

14.数据一致性: Request-Based Data Sync.

此设计方案虽因为微服务间直接的同步或异步远程的调用, 而不存在著各微服务间数据库藕合的问题, 但是, 也存在著其它需注意的地方:

l当 customer information 微服务, 删去了自身数据库中的 Customer ID: ABC001 的数据后, customer information 微服务便必需要知道, 它需同步或异步远程调用哪些的微服务?

l假如, customer information 微服务少调用了一个微服务, 则将使得整体微服务的数据, 很难再维持一致性; 因为, 这样的缺陷, 有时在数百, 甚至是数千个的微服务当中, 是相当不容易被定位到的。

lcustomer wish list 微服务与 customer preference 微服务, 将必需要负责处理自身数据库上的事务; 如：回退、确认是否有回传数据库处理确认的信息给 customer information 微服务…等等。这将增加 customer wish list 微服务与 customer preference 微服务在开发与测试上的复杂度。

l当 customer information 微服务是采用同步调用 customer wish list 微服务与 customer preference 微服务时, customer information 微服务将必需等待 customer wish list 微服务与 customer preference 微服务回传数据库处理确认的信息, 才能向其外部的使用者介面确认 Customer ID: ABC001 的数据已被成功的删除。而这将使得 customer information 微服务的外部使用者介面花费时间等待; 在性能上可能会有一不好的使用者体验。

lcustomer wish list 微服务与 customer preference 微服务都有著重复的代码, 处理著自身数据库上相同的事务。

15.数据一致性: Event-Based Data Sync.

这设计方案的优点是显而易见的:

customer information 微服务、customer wish list 微服务、customer preference 微服务之间是完全解藕的; 微服务间不存在著数据库间的藕合, 微服务间也不需知道对方是谁?

但缺点是: 开发的成本相对的较高。

III.结论:

Cloud-Native 微服务, 毫无疑问的将能使企业能快速的响应市场的变化、用户的诉求, 而能使企业能永保市场的优势与竞争力。

但, 天下没有白吃的午餐; 打造一真正的 Cloud-Native 微服务是需要更高效协作、更轻量级、更可视化的软件开发模式。

幸运的是, “Cloud-Native 微服务架构元素卡” 与 “Cloud-Native 产品级敏捷 2.0”, 为我们提供了在Cloud-Native 微服务上可高效协作、轻量级、可视化的架构设计的方法与实践。

欢迎你也来试试!