星巴克不需要两阶段提交

原文中更多想说明的是异步处理很棒以及要根据实际的需求做出合适合理的架构设计。

简单归纳几点常见的架构设计注意事项。首先没有完美的一致性方案,这个可以探究CAP原理,要么低延时/弱一致性,要么强一致/低吞吐。根据需要按需选择,在分布式领域切记高可用而不是高可靠。保证高可用,可以在必要时刻进行服务降级,将流量集中在重要的服务上面。但是对于集群的容错一定要考虑,比如可以使用「舱壁隔离」,容错模式可以选用:fail-over——立即重试,fail-fast——不重要的任务忽略,fail-back——先记录,后重试,fail-fork——同时发请求,降低失败概率。服务之间也不是平等的合作关系,而是消费者/提供者关系。对于弹性伸缩,伸缩本身是一门艺术,然而「弹性」其实没那么重要。

分布式理论第一原则:不分布。这就是说我们是在问题必须要分布处理的时候才选择分布,不分布就能极大的减少很多问题的引入。当要考虑分布时,不能一个劲的堆叠系统的复杂程度。

微服务架构,最要紧的是如何正确划分边界,微不微不重要。一个理想的划分模式是服务划分,垂直优先,比如领域驱动的设计。系统由服务组成,服务之间只能通过接口进行交互。服务独立开发、测试、发布、部署和升级。

服务划分第一原则:不要划分。这个就跟分布式理论一致了。「有必要」才进行划分。

在设计API的时候,有一种风格是REST,通过预定义有限枚举的动词配合资源导向,使用Non + Verb来表达系统的业务能力。实现方式可以选择:Json over HTTP,用资源的方式抽象接口。可以参考 Google Cloud API Design Guide

底层能力库有不一样的选择,上层会有不一样的想法。比如在出现钢结构之前,很难想象鸟巢这种建筑。可以使用容器、虚拟机做资源池化。

几个设计模式:sidecar模式,使用IPC而不是RPC。绞杀着模式,在升级系统时一部分一部分来,然后使用蓝绿部署进行热更新,可以参考Netflix在AWS的案例。

有一些很容易被曲解的地方:

  • 简单而不是简陋
  • 权衡而不是将就
  • 迭代而不是半成品