微服务的原则

围绕业务概念建模

经验表明,围绕业务的限界上下文的接口,比围绕技术概念定义的接口更加稳定。针对系统如何功过这个领域进行建模,不仅可以帮助我们形成更稳定的接口,也能确保我们能够更好的反映业务流程的变化。使用限界上下文来定义可能的领域边界。

限界上下文

接受自动化文化

大量维服务的管理

自动化测试

持续交付

自定义镜像

不可变服务器

隐藏内部实现细节

独立于其他服务,最大化独自演化能力

隐藏他们的数据库

数据泵

事件数据泵

技术无关的api

让一切都去中心化

确保团地保持对服务的所有权

内部开源模式

团队与组织保持一致

协同来替代编排或者哑中间件?

智能端点

可独立部署

单服务单主机模式

蓝/绿部署和金丝雀部署

消费者驱动的契约测试

你的消费者应该自己决定何时更新

隔离失败

不要像使用本地调用那样处理远程调用

反脆弱、超时、舱壁、断路器

可用性、一致性

高度可观察

注入合成事务

语义监控

聚合你的日志和数据

关联标识

什么时候你不应该使用微服务

不了解一个领域时。因为难找到限界上下文

从头开发时。因为领域是新的。建议先单块

构建工具和实践

逐步开始的重要性

临别赠言

尽量缩小每个决策的影响范围

持续的改变和演进系统。学会拥抱演进式架构的概念。