Cloud Native 元素卡: Cloud Native 微服务持续交付2.0

Read Time:1 Minute, 10 Second

前言:

Docker, Vagrant 帮助我们能打造出如图中的持续交付的 “价值流”:

Docker, Vagrant 使得开发人员在开发的阶段, 就能在 Production-like 的环境上进行更可信、更有效的契约测试 (Contract Test)。也就是说, 开发人员在开发的阶段, 就能藉由在 Production-like 环境上契约测试的结果, 确定自身所新增、修改的代码是否会对既有的系统、其他的开发人员的代码造成影响?
Docker, Vagrant 使得测试人员能在 Production-like 的蓝线环境上, 进行更贴近实际运维环境下的集成测试、失败测试 (Monkey Test)、A/B Test。使得 Release Management Team 能更加的确定所发布的版本的质量与对用户的价值。

所以, 我们是不是只要拥有了如上图的持续交付的 “价值流”, 就能保证我们能按照外部用户的诉求, 快速的交付, 甚至是能做到按需的交付?

当然不是。

我们还有其他的 “功课” 必需要去做; 就像不是将高速公路给建好了, 就能保证不会堵车。

我们要能按照外部用户的诉求, 快速的交付, 甚至是能做到按需的交付, 拥有能持续交付的 “价值流” 是很关键且重要的第一步。

在这很关键且重要的第一步的基础之上, 我们还必需要能做到:

1. 分析出能独立发布、独立部署的业务流(业务场景)。

2. 由每个独立发布、独立部署的业务流 (业务场景) 所形成的 “微服务” ,其内部代码的实践要能遵循 “Clean Architecture” 的原则; 以 “洋葱式” 的架构做好 “代码的隔离”。

3. 团队成员间可高效的协作。

上述的这三件事, 我们都早已清楚是必需要去做的。

但, 问题是: 我们是需要花费大量的时间先去学习些方法论; 如: 领域驱动设计, Use Case…等等; 才能做得到? 还是我们能有一轻量级、可视化的 “工具”, 就可以帮助我们省时、高效的完成?

事实上, 我们只要藉由 “卡片”; 轻量级、可视化的 “Cloud-Native 元素卡” ;就能省时、高效的做得到。

Cloud-Native 元素卡总共区分为:

Cloud-Native 微服务设计元素卡: 轻量级、可视化的 “卡片”, 协助我们能高效、有趣的完成微服务粒度(边界) 的界定、Restful API 设计、Event 架构的设计。

Cloud-Native 微服务开发元素卡: 可视化、轻量级的“卡片”, 承载著 Persistence Layer ( 使得微服务在读、写不同的数据库时; 如: MySQL, MongoDB, SqlLite, PostgreSQL; 都有一统一的接口)、 gRPC、Restful API 的样例实践代码。所以, 不仅可以协助我们能更快、更轻松的开发微服务, 更能在团队里建立起 “洋葱式架构” 的开发规范。

Cloud-Native 微服务架构元素卡: 轻量级可视化的 “卡片”, 使得我们在产品的任一版本迁移至微服务的架构时, 都能高效的找到最 “适合” 的微服务架构方案。

Cloud-Native 元素卡使得我们:

能省去学习难懂又费时的方法论。但是, 依旧是有 “规范” 的：
- 从外部的视角, 界定可独立发布、可独立部署的微服务粒度。
- 遵循著 “Clean Architecture” 的原则, 做好微服务内部开发代码的隔离。
可根据团队、产品的现况, 加入适合团队、适合产品的元素卡。使得团队可永续的积累著, 可使团队高效开发微服务的优秀实践、架构方案、开发模式。
轻量级、可视化的 “卡片” 使得团队的产品经理、架构师、开发人员、测试人员都可更易于互相的沟通、交流、协作。而可更高效、更准确的打造出能快速响应外部变化的 Cloud-Native 微服务。

后续我将会从 Cloud-Native 元素卡出发, 持续的探讨 Cloud-Native 微服务开发。我也会再加入其他的Cloud-Native 元素卡; 如: Event Sourcing, CQRS, Security, Contract Test, DevOps…等等。

期待著你的持续的关注。

请参考:

Cloud-Native 微服务设计元素卡