前言:

 

 

 

 

 

 

 

 

 

 

 

 

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; 都有一统一的接口) gRPCRestful API 的样例实践代码。所以, 不仅可以协助我们能更快、更轻松的开发微服务, 更能在团队里建立起 洋葱式架构的开发规范。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

结论:

Cloud-Native 元素卡使得我们:

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

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

期待著你的持续的关注。

 

请参考:

Cloud-Native 微服务设计元素卡

Cloud-Native 微服务开发元素卡

Cloud-Native 微服务架构元素卡

 

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据