原文介绍了 LMAX 支持高性能、低延迟的架构，还介绍了 Disruptor 这个框架的设计缘由。
LMAX 用 3Ghz 的 CPU 单线程处理达到 600w TPS，意味着要在 500 个时钟周期内处理完一个事务。（dual-socket quad-core，32GB RAM）
LMAX 整体架构：
只是简单的 Java 代码，不依赖于任何框架。单线程执行，全内存操作, 顺序地获取输入的消息。
要操作的数据全在内存里。好处有两点：快 和 简化了编程（没有对象/关系映射）。
用 Event Sourcing 事件溯源机制来保证 BLP 的状态是可以重建的，输入事件由 input disruptor 来进行持久化。事件溯源机制可以采用快照的方式来缩短重建需要的时间。
LMAX 采用多个 BLP 同时处理同样的事件（两个在同一个数据中心，第三个在灾备中心），但只有一个 BLP 的输出是有效的。当存活的 processor 失败时，系统切换到另一个。
事件溯源的另一个好处是诊断方便，可以把事件拷贝到开发环境进行重放。
系统 泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体（能力）。
从逻辑的角度拆分系统后，得到的单元就是“模块”，从物理的角度拆分系统后，得到的单元就是“组件”。划分模块的主要目的是职责分离，划分组件的主要目的是单元复用。
框架是组件规范，提供基础功能的产品。软件架构指软件系统的“基础结构”，创造这些基础结构的准则，以及这些结构的描述。框架关注的是“规范”，架构关注的是“结构”。
软件架构指软件系统的顶层结构：
* 架构需要明确系统包含哪些“个体”，个体可以是 子系统、模块、组件等。
* 架构需要明确个体的运作和协作的规则。
* 顶层结构可以更好地区分系统和子系统。
自话：软件架构确定了系统中应该包含哪些个体，以及个体之间应该如何协作，以提供某种能力，从而实现系统的价值。
“模块”“对象”“组件”本质上都是对达到一定规模的软件进行拆分，区别只是在于随着软件的复杂度不断增加，拆分的粒度越来越粗，拆分的层次越来越高。
架构设计的主要目的是为了解决软件系统复杂度带来的问题。
架构设计首先要分析系统的复杂度所在，然后针对这些复杂度进行设计、制定方案。
软件系统中高性能带来的复杂度主要体现在两方面，一方面是单台计算机内部为了提高性能带来的复杂度；另一方面是多态计算机集群为了高性能带来的复杂度。
系统的高可用本质都是通过“冗余”来实现的，方法是增加机器。
高性能增加机器的目的在于“提升”处理性能，高可用增加机器的目的在于“冗余”处理单元。
存储高可用的难点不在于如何备份数据，而在于如何减少或者规避数据不一致对业务造成的影响。
高可用状态决策：无论是计算高可用还是存储高可用，其基础都是“状态决策”，即系统能够判断当前状态是正常还是异常，如果出现异常就要采取行动来保证高可用。
决策方式：
* 独裁式：所有冗余的个体向一个独立的决策主体上报状态信息，决策者进行决策。问题在于决策者本身是个单点。
* 协商式：两个独立的个体通过交流信息，然后根据规则进行决策，最常用的协商式决策就是主备决策。难点在于两者的信息交换出现问题时如何决策。
* 民主式：指多个独立的个体通过投票的方式来进行决策。缺陷是脑裂：原来统一的集群因为连接中断，造成两个独立分隔的子集群，每个子集群单独进行选举，选出两个决策者。解决方法是要求“投票节点数必须超过系统总结点数一半”。
可扩展性是指为了应对将来需求变化而提供的一种扩展能力。
设计具备良好可扩展性的系统，有两个基本条件：正确预测变化、完美封装变化。
预测变化的复杂性在于：不能每个设计点都考虑可扩展性、不能完全不考虑可扩展性、所有的预测都存在出错的可能性。
设计具备良好可扩展性的系统，有两个思考角度：从业务维度，对业务深入理解，对可预计的业务变化进行预测；从技术维度，利用扩展性好的技术，实现对变化的封装。
应对变化的常见方案一是将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”。
方案二是提炼出一个“抽象层”和一个“实现层”，抽象是文档的，实现可根据具体业务需要定制开发，加入新的功能时，只需要增加新的实现，无需修改抽象层。
举例：设计一个支付网关对接不同的支付机构，为业务系统提供支付能力。每家支付机构的通信方式、请求/响应格式都是不一样的，但基本参数都是四要素信息(银行卡号、预留手机号、姓名、身份证号)、扣款金额等，扣款结果一般就是成功/失败/等通知，因此可以抽象出统一的接口，对接不同支付机构的具体实现类实现这个接口、完成具体的调用逻辑，当要对接新的支付机构时只需要添加一个实现类；业务系统只需访问这个统一的接口。
第三部分未完结，挖坑先。。。
我们只在我们没有其他选择时改变单体 (monolithic) 系统。与其说是敏捷地抓住机会，我们考虑它是否确实值得倾覆我们称为纸牌屋的企业系统的微妙平衡。通常，机会很快就消失了，被快速的公司抓住。
Flaus Schwab: 在新世界，不是大鱼吃小鱼，是快鱼吃慢鱼。
基于微服务的架构是个简单的概念：它提倡用一组小的、隔离的服务来创建系统。这些服务拥有它自己的数据，各自是独立的、可扩展且对失败有弹性。服务集成其他服务来构建一个内聚的系统，它比我们当前构建的典型企业系统更灵活。
传统企业系统设计为单体应用，难以扩展，难以理解且难以维护。单体应用可能很快就变成噩梦，扼杀创新、进度和乐趣。单体应用导致的负面作用对一个公司可能是灾难性的，从底层的士气到高层雇员的周转，从阻止公司雇佣顶尖工程天才到失去市场机会，在极端情况下，甚至是公司的失败。
战争故事通常听起来是这样的：“我们终于做了决定来改变我们的 Java EE 应用，在得到管理层批准后。然后我们经过长达数月的大设计，在我们最终开始构建点东西之前。但我们构建期间的大多数时间都花在尝试弄清楚单体应用真正做了什么。我们因害怕而瘫痪，担心一个小的错误可能导致非预期的、未知的副作用。最终，在数月的担忧、害怕和艰难工作后，改变实现了，但地狱也打开了。”
这样的经历会加强害怕，使我们瘫痪更严重。这就是系统、公司如何停滞的。如果有更好的方式呢？
Steve Jobs：You’ve got to start with the customer experience and work back towards the technology 。
微服务的客户是投资于系统的组织，所以让我们从客户开始：开发人员、架构师和关键利益相关者。
Helen Keller：Although the world is full of suffering, it is also full of the overcomming of it .
因为技术原因，微服务是软件里不纯粹的下一代设计演进。微服务这个词汇呈现的思想在我们进入面向服务的架构（SOA, Service Oriented Architecture）之前已经遍布各处。阻止我们采用微服务内嵌的概念的特定技术约束已经进入下一水平：单台机器运行着单个内核处理器，慢速的网络，昂贵的磁盘，昂贵的 RAM，组织结构是个单体。像把系统组织成一个定义良好的、有单一职责的系统的想法不是新的。
快进到 2016 年，阻止我们采用微服务的技术限制已经消失了。网络是快速的，磁盘是便宜的（且更快速），RAM 是便宜的，多核处理器是便宜的，云架构正在彻底改革我们如何设计、部署系统。现在，我们终于可以考虑着客户来构建我们的系统。
设计和编写软件是有趣的，这是大多数的我们进入软件行业的初衷。微服务不仅仅是一序列的原则和技术。它们以一种更专业的方式来达成复杂问题的系统设计。
微服务允许我们以组织我们团队的方式来构建系统，在团队成员之间划分职责，保证他们自由处理自己的工作。当我们理顺了我们的系统，我们把权利从中央治理主体移交到小团队里，小团队可以快速抓住机会并保持敏捷，因为他们明白 他们控制的、有定义良好的边界的软件。