From Microliths to Microsystems

原文地址 | Presentation | Slides

关键词：微服务、event-first DDD、Reactive

大纲

• 避免构建mini-moniliths，即microliths。
• 构建resilient和elastic的系统。
• 最小化系统内部的耦合度，最小化系统内部的通信。
• 使用reactive programming，reactive system design，eventual consistency。
• 把无状态行为从有状态实体分离出来，更容易扩展性。
• 实践event-first DDD。

Eachmicroservice needs to be designed as a distributed system: a microsystem. We need to move from microliths to microsystems.

microliths既非resilient也不elastic。根据 The Reactive Manifesto ，要达成resilient和elastic需要：

• Decentralised architecture
• Bulkheading
• Replication
• Failure detection
• Supervision
• Gossip protocols
• Self-organisation
• Location transparency

一切信息都有延迟，我们总是通过分布式系统通信来窥视过去发生的事情。开发者应尽量减少耦合与通信，并拥抱最终一致性。

作者推荐了两个设计微服务系统的工具：

工具一：Reactive desgin

• Reactive programming，比如RxJava，可以帮助让单个服务实例高性能以及高效。
• 基于异步消息的Reactive系统可以帮助构建elastic and resilient的分布式系统。
• 实现异步和非阻塞微服务可以更有效的利用资源，降低共享资源的争用。
• 总是使用 back-pressure ，一个快速系统不应该是慢速系统过载。

工具二：Event-first DDD

• 每一个微服务应该被设计成为一个微系统，无状态行为要从有状态实体中剥离出来，使得独立服务能够具有扩展性。
• 实体可以称为确定性和一致性的安全岛，但是扩展无状态行为易，扩展有状态实体难。
• 开发者应该实践event-first DDD，从一致性边界的角度思考 data on the inside 代表现在，data from the outside代表过去，而command则代表未来的动作。

Don’t focus on the things - the nouns. Focus on what happens - the events! Let the events define the bounded context.

一个微服务应该包含一切可变状态并发布事实，所谓事实就是event。event log应该是一个“代表过去的数据库”， single immutable source of truth 。event logging可以避免臭名昭著的 object-relational impedance mismatch ，读写问题可以通过 CQRS 与 Event sourcing 解开。开发者不应该基于 assuming distributed transactions 来构建大型可扩展应用，而应该使用“guess, apoligize, compensate”（和TCC、Saga类似）协议。

延伸阅读