概要

本文中我们将讨论如何借助Kafka实现分布式消息管理，使用事件溯源（Event Sourcing）模式实现原子化数据处理，使用CQRS模式（Command-Query Responsibility Segregation ）实现查询职责分离，使用消费者群组解决单点故障问题，理解分布式协调框架Zookeeper的运行机制。整个应用的代码实现使用Go语言描述。

• 部分 引子、环境准备、整体设计及实现
• 第二部分 消息消费者及其集群化
• 第三部分 测试驱动开发、Docker部署和持续集成

部分 引子、环境准备、整体设计及实现

为什么需要微服务

微服务本身并不算什么新概念，它要解决的问题在软件工程历史中早已经有人提出：解耦、扩展性、灵活性，解决“烂架构”膨胀后带来的复杂度问题。

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.（任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的通信结构保持一致）
– Melvyn Conway, 1967

《人月神话》：Adding manpower to a late software project makes it later –Fred Brooks, (1975)

为了赶进度加程序员就像用水去灭油锅里的火一样，原因在于：沟通成本 = n(n-1)/2，沟通成本随着项目或者组织的人员增加呈指数级增长。很多项目在经过一段时间的发展之后，都会有不少恐龙级代码，无人敢挑战。比如一个类的规模就多达数千行，核心方法近千行，大量重复代码，每次调整都以失败告终。庞大的系统规模导致团队新成员接手困难，项目组人员增加导致的代码冲突问题，系统复杂度的增加导致的不确定上线风险、引入新技术困难等。

微服务 (Microservices)是解决这些困难的众多方案之一。它本质上是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。

真正构建一个微服务是非常具有挑战性的。其中一个重要的挑战就是原子化————如何处理分布式数据，如何设计服务的粒度。例如，常见的客户、工单场景，如果拆分成两个服务，查询都变成了一个难题：

select * from order o, customer c
  where o.customer_id = c.id
  and o.gross_amount > 50000
  and o.status = 'PAID'
  and c.country = 'INDONESIA';