识别复杂度心得

架构设计由需求所驱动，本质目的是为了解决软件系统的复杂性；为此，我们在进行架构设计时，需要以理解需求为前提，首要进行系统复杂性的分析。具体做法是：

（1）构建复杂度的来源清单——高性能、可用性、扩展性、安全、低成本、规模等。

（2）结合需求、技术、团队、资源等对上述复杂度逐一分析是否需要？是否关键？

“高性能”主要从软件系统未来的TPS、响应时间、服务器资源利用率等客观指标，也可以从用户的主观感受方面去考虑。

“可用性”主要从服务不中断等质量属性，符合行业政策、国家法规等方面去考虑。

“扩展性”则主要从功能需求的未来变更幅度等方面去考虑。

（3）按照上述的分析结论，得到复杂度按照优先级的排序清单，越是排在前面的复杂度，就越关键，就越优先解决。

需要特别注意的是：随着所处的业务阶段不同、外部的技术条件和环境的不同，得到的复杂度问题的优先级排序就会有所不同。一切皆变化。

说下之前改造的一个系统，当时是这个系统从其他系统同步数据，经过一整套流程后将数据拆解到本地库的各个业务表中。
原来的系统是一个单机多线程程序，到了大促的时候延时非常厉害，因为马上又要大促了，首先想到的是扩展性的问题，于是就做了无状态服务拆分，可以横向扩展。在这过程成因为要控制单个同步实体任务的并发在处理幂等性上也花很大的功夫。做完这个后，又对非关键流程做了消息解耦，提高主流程的处理速度。
系统上线后运行稳定，但是到了大促当日发现速度提升很有限，将机器扩展到10台速度只提升了2-3倍，而且数据库和应用压力都很小。
后来分析下来瓶颈竟然是在数据库中间件上。其他系统大量的慢sql导致中间件处排队严重。
现在想起来，其实还是改造前优先级没搞清楚，根据之前的经验就把问题归结到扩展性上，投入了大部分精力在扩展性和可用性上，而没有对原来单机系统的性能做完整的测试和评估。其实当时做一个单机程序的压测大概就可以判断出问题所在(改造过程中也发现老的程序确实有bug)。还有就是高性能的优先级远大于扩展性和可用性，因为这个系统重启的影响非常小。改造的时候过于理想化的，想做一个各个方面均衡完善的架构

分析现在做的采集系统，主要是控制单系统融合了（前端业务，任务调度,分发，自实现系统内缓存，采集机状态管理，数据入库功能）。采集机主要实现了所有的采集功能，采集机是集群的。业务性能要求比较低，页面基本没什么人访问，后台业务主要分采集项，频繁的一点就任务A是10分钟1W个任务（不间断），任务B是4小时内完成2W个任务，分析业务不是瓶颈，但是2W个任务由于依赖客户提供的登入方式实际采集耗时在10小时左右（这点问题应该需要协调客户处理或者换方式实现）。
    主要复杂度在于系统的耦合性，控制单系统功能太多了，想添加一个任务逻辑的复杂模块，很难加。想拆分成子系统（分为前端子系统，缓存子系统，采集机管理子系统，数据入库子系统，任务调度子系统。前二个优先级比较高，后面的可以等需要的时候拆分），把单系统内的调用替换成rpc框架的系统间调用，但是系统间调用比原来的调用多了一种超时状态。原来的系统状态性比较强，如果远程调用的不确定性，可能需要业务改为无状态的。那么需要改动的量比较大。（rpc调用异常的处理方式了结的比较少，希望老师给点指点，谢谢）。
    其次复杂度在于高可用，我们的系统宕机时间没有那么严格，但是需要在一定时间内切换，30分钟即可。采集机集群通过任务轮询，已经实现了高可用。但是控制单系统做高可用有一个问题是单系统实现了内部的缓存，如果不把缓存抽离出来就会有一致性问题。然后实现主备，单节点可用，出了故障另外一台设备升级为主节点，通过协商的方式。（脑裂的情况暂不考虑，客户的内网相对稳定。通过监控人工来恢复。）