好的系统有各自的好，傻逼的系统有一样的傻逼行为：性能差！
系统非功能性指标有林林总总，除了我们说的可用性之外，性能好是最直观的，和用户抱怨最多的一项。
2015年的时候，只有总共十几个开发人员，两个已经要累死的测试，按照订单总量计算，只有300万，但是系统已经不堪重负。
这个系统是一个业务操作系统。用户可以手工的，或者表格导入的形式，或者接口导入的形式创建订单。而在我加入以后不久，又增加了通过接口导出创建订单后的自动分配功能。当时的主要功能点在于，对于任何一个订单，生命周期是贯穿不同的操作步骤的，而每一步的操作，带来的是基于状态机的状态变更。这听起来就像是一个工作流系统。而，自动分配功能就是根据计算逻辑，做自动的状态转换的过程。
听起来很美，不过，正是这种功能，让我们吃了巨大的苦头……
系统性能调优的切入点是慢查询，GC频率。然后……你知道，会有一些效果。比如，有慢查询，就调索引，GC过高，就调堆内存比例，大小。之后的几次系统不稳定情况下，初始的调优思路也是如此。
然而，回头看下来，这种头疼医头，脚疼医脚的方式是让一切变坏的起点。
文化的不同导致后期中外团队有各种争论和不配合。抛开这些，有很多来自其他团队的观点是正确的。比如在设计上，应该保持无索引设计的思路，而不是依赖于索引做方案。这样，随着系统的变大，仍有足够的调优空间作为缓冲。
回到当时的系统状态。早期外包开发，导致框架选择上偏向快速开发工具。最典型的是使用基于GWT的展示端，以及脱离native SQL的hibernate。这些工具在早期发挥了巨大作用，但是同样包装过度导致有额外的资源消耗。比如，hibernate，对象关联导致级联查询过多，而且开发人员很容易出现错用的情况。
这个时候是第一个系统架构升级的时间节点，而当时的融资状况是A轮。快速增长和架构升级是需要小心翼翼的进行。回溯当时的技术决策：
数据库调优，优化慢查询，但是同时做了一个非常错误的决定：合并表以减少join。这个决定是灾难性的，导致后期数据库性能急剧下降。
拆分手机端调用的后台服务。这个决定现在看来，也是不成功的。但是迈出了拆分服务的第一步。从一个巨大的单体应用，包含WEB端，主业务逻辑，和手机调用API等所有资源请求主体，变成了手机调用校验逻辑，这部分查询最频繁的部分，拥有了自己的数据库。从而，减少了主数据库的连接压力。但是，因为主体业务逻辑仍然保留在主服务上，导致最终数据落盘仍在主库上，并没有实质性的拆分完成。
此外，对于订单匹配计算逻辑，内存加载消耗，CPU消耗，以及数据库查询消耗都非常大的情况下，做了缓存化处理。虽然，仍然是利用推资源的方式去解决问题，但是这部分的决定被认为是正确的。
系统暂时稳住了，然而，下一波很快就来了……
