• 每个系统都有它最核心的指标。比如在收单领域：进件系统第一重要的是保证入件准确，第二重要的是保证上单效率。清结算系统第一重要的是保证准确打款，第二重要的是保证及时打款。因为涉及交易商家、用户之间的资金流转，对于核心交易来说：第一重要的是稳定性，第二重要的还是稳定性。

问题引发

作为一个平台部门，我们的理想是第一阶段快速支持业务；第二阶段把控好一个方向；第三阶段观察好市场的方向，自己去引领一个大方向。

理想很丰满，现实是自从2017年初的每日几十万订单，到年底时，单日订单已经突破700万，系统面临着巨大的挑战。支付通道在增多；链路在加长；系统复杂性也相应增加。从最初的POS机到后来的二维码产品，小白盒、小黑盒、秒付……产品的多元化，系统的定位也在时刻的发生着变化。而系统对于变化的应对速度像是一个在和兔子赛跑的乌龟。

由于业务的快速增长，就算系统没有任何发版升级，也会突然出现一些事故。事故出现的频率越来越高，系统自身的升级，也经常是困难重重。基础设施升级、上下游升级，经常会发生“蝴蝶效应”，毫无征兆的受到影响。

因为业界的标准是后验的指标，考虑到对于平时工作的指导意义，我们通常采用服务治理平台OCTO来统计可用性。计算方法是：

问题解决

1. 发生频率要低之别人死我们不死

1.1 消除依赖、弱化依赖和控制依赖

用STAR法则举一个场景：

情境(situation)

我们要设计一个系统A，完成：使用我们美团点评的POS机，通过系统A连接银行进行付款，我们会有一些满减，使用积分等优惠活动。

任务(task)

分析一下对于系统A的显性需求和隐性需求：

1. 需要接收上游传过来的参数，参数里包含商家信息、用户信息、设备信息、优惠信息。
2. 生成单号，将交易的订单信息落库。
3. 敏感信息要加密。
4. 要调用下游银行的接口。
5. 要支持退款。
6. 要把订单信息同步给积分核销等部门。
7. 要能给商家一个查看订单的界面。
8. 要能给商家进行收款的结算。

基于以上需求，分析一下怎样才能让里面的最核心链路“使用POS机付款”稳定。

行动(action)

分析一下：需求1到4是付款必需链路，可以做在一个子系统里，姑且称之为收款子系统。5到8各自独立，每个都可以作为一个子系统来做，具体情况和开发人员数量、维护成本等有关系。

值得注意的是需求5-8和收款子系统的依赖关系并没有功能上的依赖，只有数据上的依赖。即他们都要依赖生成的订单数据。

收款子系统是整个系统的核心，对稳定性要求非常高。其他子系统出了问题，收款子系统不能受到影响。

基于上面分析，我们需要做一个收款子系统和其他子系统之间的一个解耦，统一管理给其他系统的数据。这里称为“订阅转发子系统”，只要保证这个系统不影响收款子系统的稳定即可。

粗略架构图如下：

解决方法：

• 将查询分成实时查询、近实时查询和离线查询。实时查询可穿透数据库，其它的不走数据库，可以用Elasticsearch来实现一个查询中心，处理近实时查询和离线查询。
• 读写分离。写走主库，读走从库。
• 索引优化。索引过多会影响数据库写性能。索引不够查询会慢。DBA建议一个数据表的索引数不超过4个。
• 不允许出现大表。MySQL数据库的一张数据表当数据量达到千万级，效率开始急剧下降。

王国维 在《人间词话》里谈到了治学经验，他说：古今之成大事业、大学问者，必经过三种之境界：

第一种境界 昨夜西风凋碧树。独上高楼，望尽天涯路。

第二种境界 衣带渐宽终不悔，为伊消得人憔悴。

第三种境界 众里寻他千百度，蓦然回首，那人却在，灯火阑珊处。