部分概念性的文字来自于《1.pptx》，由原人民银行科技司李副司长在今年7月《金融电子化杂志》培训所授内容。如觉侵权，请联系作者删除。

人们普遍认为一个分布式系统，必须遵循的是CAP原则，即是“数据一致性”、“可用性”、“分区容错性”。无论你设计的分布式系统，从系统上分拆也好，从子系统分拆也好，计算分拆也好，存储分拆也好，都逃不出这个概念。

数据一致性很容易理解，就是没有脏数据。你的数据分别存放于系统的各个地方，主-从机制确保数据不容易丢失。但是也要有一个机制能保证应用读取到的数据和存放的数据不能有不一致的情况。比如某鹅厂改造的开源MySQL，数据库主节点向从节点分发数据并等待从节点写入成功的回执。为了性能，他们的做法是写LOG日志成功即可返回。

可用性包括两个概念：一是稳定性，服务不会挂；二是性能，如果服务延迟长，超时多，那和挂咸鱼有什么区别。大多数分布式集群对于可用性采取的策略都差不多，就是以大量相对便宜的PC服务器来取代国际商用的大小型机。

分区容错性指的是网络分区。当数据从一个物理节点传输到多个物理节点后，设备之间的网络延时就会引起问题。因为由于容错容灾的需要，物理节点和节点的通讯有可能处于同一个交换机上，有可能处于不同城市之间，还有可能处于不同的大洲上。所以，使用同步通讯交换数据是不被推荐的，节点服务间的通讯大多数采取异步通讯的方式。

分布式架构的核心理念是“并行拆分和横向扩展”，系统的各个功能部分采用松耦合的方式并行运行，并支持横向扩展和容错恢复的机制。所以基于这个理念，分布式架构相对于集中式架构具备不少优点。

系统扩展能力较强，采用通用硬件扩展计算和存储能力可以提升系统处理能力，满足业务不断增长的需求；系统运行效率较高，在对系统各个环节合理拆分的基础上，透过并行处理进一步突破传统串行处理存在的效率瓶颈；系统运行可靠性较好，将系统拆分后并行运行在多台相同的设备上，即使存在单点故障，整个系统认可正常运转或者可控恢复；系统成本优势明显，分布式系统基于相对廉价的通用计算和存储设备构建，获取相同处理能力的成本低于传统架构。

然而需要注意的是，分布式系统不是银弹。分布式系统不是救世主，并不是所有的应用场景存在瓶颈都能使用这个技术解决。不同的业务形态所面临的挑战不同，使用的架构设计也会有差异，通常都需要对具体问题具体分析，没有谁是最好架构的说法。不管哪种业务，不管何种分布式系统，其基本思想是想通的、一致的。

要做好一个好的商用场景分布式架构设计，有两点是必要优先考虑的：一致性事务和微服务粒度。

事务一致性考虑还能细分为，强事务一致性还是弱事务一致性。前面的名词好理解，弱事务一致性其实就是“最终事务一致性”。什么意思呢，给大家举个例子。你用银行卡去买水果，水果店看你用卡买就很不高兴。刷卡后，这笔交易正常情况下只会有两个状态：成功、失败。失败的原因很多种，你密码输出啦，账户上没钱啦，发卡行受理失败啦，以及其他。如果这笔交易通讯失败了，发卡行无论如何都会尝试冲正，要把你可能在途的钱追回来。这个动作就是所谓强事务一致性保证。

然后第二天你没带银行卡去买钻戒，珠宝店老板看你用微信买就很不高兴。你验证支付指纹以后，你微信上的钱包余额少了两块钱，交易也显示成功了。“且慢！”老板一脸横肉的拦住你，“我微信钱包没有增加钱。你要么给钱，不然就给人头。”你百口莫辩，小心翼翼的说，“要不您刷新一下看看？”老板将信将疑的刷了四百二十九次，高高兴兴的说，“到帐了到帐了，你可以走了。”这就是弱事务一致性，在给定的一段时间内事务可以达到最终一致性。你长吁了一口气，今天总算是见识到弱事务一致性的厉害了。坐上地铁，你发现没拿钻戒。

服务粒度问题其实是一个非常敏感的话题。做过ESB服务治理的你会在深夜里大喊着醒来，是因为按照服务治理的要求将一个接口拆散成两个服务，下游系统化为厉鬼要求你给他们做服务组合。如果粒度小，那么重用性就好，但是如果场景里查询次数多了，数据配装的次数也会增加；如果粒度大了，会造成场景中的冗余服务增多，管理和解析都会带来成本的提升。

这次我们的互(mì)金(mì)项目，有系统的微服务粒度做的太细了，于是在测试中通过××平台查看调用链路的时候，发现触发到好多次跨域调用。打开代码一看，原来是要去获取参数的地方，都走到公共层触发获取另一个服务了。解决问题很多，无非是用缓存或者单例，具体情况具体分析。

本文说教的地方过多，然而是肉最多的地方。其他两篇承上启下的摘录于下：
后现代主义的编程时代（一）| 后现代主义的编程时代（三）