(1) 所有的业务逻辑都在同一个物理部署单元，不同业务之间互相影响（例如退款业务出现问题，但是与此同时把支付业务也拖垮了）； (2) 随着业务流量的增大，数据库的压力逐渐增大，数据库的偶尔波动造成系统不稳定，对用户的支付体验影响很大； (3) 支付、退款等状态的同步很大程度上依赖第三方支付渠道的异步通知，一旦第三方支付渠道出现问题，造成大量客诉，用户体验很差，开发、运营都很被动。

所谓高可用性指的是系统如何保证比较高的服务可用率，在出现故障时如何应对，包括及时发现、故障转移、尽快从故障中恢复等等。本文主要以点评的交易系统的演进为主来描述如何做到高可用，并结合了一些自己的经验。需要强调的是，高可用性只是一个结果，应该更多地关注迭代过程，关注业务发展。

在分布式系统中，每一个机器节点虽然都能明确的知道自己执行的事务是成功还是失败，但是却无法知道其他分布式节点的事务执行情况。因此，当一个事务要跨越多个分布式节点的时候（比如，淘宝下单流程，下单系统和库存系统可能就是分别部署在不同的分布式节点中），为了保证该事务可以满足ACID，就要引入一个协调者（Cooradinator）。其他的节点被称为参与者（Participant）。协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务进行提交。

Netty的包名从org.jboss.netty改为io.netty，因为我们不在是JBoss.org的一部分了。 二进制JAR包被分为了多个子模块以便用户能够从类路径中去掉非必需的特性。当前的结构如下：