党建百年，矛盾论指导架构设计

“在复杂事物的发展过程中，有许多的矛盾存在，其中必有一种是主要的矛盾，由于它的存在和发展规定或影响着其他矛盾的存在和发展。”

——《矛盾论》

辩证唯物主义认为，世界上任何事物都是矛盾的统一体，事物是发展的，系统亦然。系统也是矛盾的统一体，随着业务的发展，内部的各种矛盾在不同业务阶段又相互转化，相互影响，不同阶段其中一种矛盾必然扮演主要矛盾的角色。架构设计的目的就是找出这些矛盾，并识别其中的主要矛盾并解决，从而推动系统的演进。所以用矛盾论的哲学理论来指导我们架构设计或者进行架构评审是完全可行的，大致可分为两部分：

一．针对性的矛盾识别

首先就是要找出系统所有的矛盾或疑似矛盾，我们的原则就是“宁可错杀，不可放过”。毕竟导致系统复杂性的根源也就有限的几类。主要归结为三高一易，规模，安全，成本。这里三高是指高性能，高可用，高并发通常是针对系统架构设计层面的，而一易就是易扩展。

高性能，一个是单次请求响应时间短，要求更高的 TPS。另一个是单位时间内处理更多的请求，偏重于吞吐量。这个时候就要看系统是属于面向 C 端展示系统还是偏向后端业务执行系统了，C 端系统要求更高的 TPS，而业务执行系统则要更吞吐量。

高可用，字面意思就是无中断，但实际情况是无论从软件，硬件再到外部环境都可能导致系统中断。软件中引入 bug 导致会系统中断，硬件方面服务器宕机，网络故障也会导致系统中断。外部环境更加不可控，如天灾导致市政断电，人祸导致运营商光纤中断等等。针对措施只有冗余，就要从系统中断期间产生的业务代价来决策何种程度的冗余。

高并发，一个是总体访问量大，针对产品用户体量或者业务量大，通常是产品到发展期开始考虑，成熟期后到达峰值。一个是瞬时访问量大，产品的某个活动带来的流量，例如抢购，都是针对业务特性和量级综合考虑的。

易扩展，则更多是代码架构，虽然架构一词出自于建筑行业，对建筑来说永恒是主题，对软件来说变化才是永恒。新的需求总会不断提出来，因此可扩展性显得尤其重要。良好的可扩展性就是能很好的兼容业务未来的变化，做到的前提就是对业务未来的预测。我们所熟知的天气预报都时常误报，实在无法苛责对业务未来的发展模式，方向和规模的预测，特别是长期预测的准确。能做到的是根据现在的状况，趋势性的预估短期发展的预测做好兼容。

规模，更多是对数据架构设计的，针对数据量级考虑要不要分库分表，要不要上大数据全家桶等等。安全，简单来说就是防偷和放抢。防偷就是维护数据安全性，防安全漏洞，防数据窃取，篡改。防抢就是预防来自网络的暴力破坏了，维护系统安全。成本，一个是经济上，大量硬件资源，人力资源投入带来的业务价值是否值得。一个是技术债，举债前行未来需要多大代价偿还。

二． 结合现状辨别主要矛盾

上面罗列了系统近乎所有矛盾点，行业头部企业的架构也是经历无数考验证明了其优秀，直接套用是不是省去了辨别麻烦？其实不然！用“汝之蜜糖，吾之砒霜“来形容架构套用再合适不过了。虽处同一行业，但是业务模式，操作类型，业态都千差万别，即使针对自身同一种业务模式不同发展阶段主要矛盾也是不同的，所以最重要的一点也是最常见的问题防止过度设计。一个二十多人的团队要开发一个垂直领域的电商系统，一套高大上的架构设计方案唯一作用就是显示了架构师的“秀儿“。复杂架构方案的落地本就不是容易的事情，利益各方争执不休，最终勉强落地，少则十几个子系统的设计导致开发阶段效率低下，子系统间关系复杂，不断出现问题，而且不易定位。投入大量的人力物力财力后产品上线，设计的承载 5000tps 的系统实际量不足 100tps，呜呼哀哉！

所以架构设计要贴合产品业务现状。产品初创期唯一要考虑的就是活下去，这期间成本就是主要矛盾，艰难的活着优于壮烈的死去。随着产品不断迭代优化，在市场上初步站稳脚。用户量级和业务量级稳步提升，这个时期各类矛盾凸显，不易判断主要矛盾，主要还是根据业务实际，提升用户留存率还是继续拓展业务规模等等，期间高性能，高并发，易扩展，数据规模都可能交互扮演主要矛盾，切忌贪大求全。产品成熟期，是占有了相当的市场规模有了一定的资源积累，更多考虑是高可用和安全。最后随着市场瓜分殆尽，业务出现萎缩，产品进入最后一个生命周期，这期间的重点矛盾又回归到成本上。当然上面是针对产品的整个生命周期来看的，细化到具体阶段，可能会有变动，万变不离其宗：合适的能随着业务发展而演进的架构就是好架构！