应用架构——由需求和缺陷衍生的复杂之树

应用架构的起源

任何一个软件的产生只有满足或缓解了人类在现实生活中的需要，才具有实际意义和发展前途。软件就是依托硬件的高速处理和传输信息的优势（主要指计算机和网络），用来提升工作产出效率的工具。然而，硬件本身具有其固有的可靠性、容量、速度等诸多方面的限制，人类思维和记忆同样具有类似的局限性。为了克服这些问题，确保软硬件整体具有高可用性，我们历代的系统工程师们总结出了一系列的方法，其中系统架构设计居于中心位置。

即使我们使用了各种架构方案，却仍然会由于采用的方案本身引入其他一些无法回避的缺陷，而针对这些次生缺陷，我们又要设计一些补救方案，这些补救方案的数量和细节往往繁多，足以构成一个子集系统。通常不懂软件开发的需求提出人员，往往只会要求开发人员给出一个满足需要的软件成果，以为只要写出满足当前需要的代码即可，把问题想得简单。而有经验的开发人员却知道硬件系统并不100%可靠，写代码的人的思维也有诸多局限，业务需求的变化也近乎无穷无尽，在有限的时间和硬件条件下完成一个可用的软件系统并不容易，需要综合权衡考虑多种要素。合理划分模块，通过提高每个模块的性能从而提升应用整体性能的方案，即为应用架构。

应用架构的演进

随着硬件功能和性能的不断进步，原来代码运行的速率和内存的限制的放松，给予了架构师新的思路和选择；市场的竞争也对软件的开发、部署、运维的效率提出了更高的要求，软件架构的演变大多由此而来。每次的架构变动都是迎合当时的需求和限制而来，解决了当时出现的可解决的问题。

最初的传统垂直应用架构（mvc和3层架构），解决了数据展示、业务处理、数据存取三个层面解耦问题，显著提升了代码的开发和维护效率。但是，随着单体应用代码规模的不断扩大，编译时间过长、代码重复率大、系统可靠性变差、维护定制困难、上线周期长的问题逐渐显露出来。

为了解决传统垂直应用架构的问题，后来出现了RPC架构，将核心业务功能拆分，分别部署到不同的进程中，通过网络通信实现业务工程的互通。从传统垂直应用架构到RPC架构是一个巨大的跨越，是一个从单体应用到分布式应用的变化。利用分布式条件下多个机器的协同运作，解决了单个机器运行速率和空间的限制，同时通过主备机器的切换实现了服务不间断运行，提高了系统的可靠性。而在代码层面上，为功能模块的解耦提供了现实帮助，有利于服务功能的升级维护。

但是随着上线服务数量的急剧膨胀，最初的RPC框架并没有考虑到服务依赖的复杂性、负载均衡的可靠性、业务模块调用路径的耦合性、安全策略的薄弱性、运维工作的复杂性等问题暴露出来。这时对于服务治理的需求日趋迫切，SOA服务化架构应用而生。SOA架构从本质上是一系列设计原则，旨在设计一个功能复用度高、契约明确、模块间松耦合、无状态、自发现的系统。随着服务化实践的不断深入，服务规模也越来越大。敏捷开发要求的迭代开发、持续快速的部署交付等很难满足。

这时，进一步细分服务粒度、多进程部署、分布式服务框架、运行态动态治理、灰度发布、独立化设计模块（即使代码重复）等手段出现，组成了新的应用架构风格——微服务架构（MSA）。

参考资料：《分布式服务框架原理与实践》李林锋