初探架构设计
架构设计的主要目的是为了解决软件系统复杂度带来的问题 架构、框架、组件、模块、系统 OLAP（Online Analytical Processing）在线分析处理 架构是顶层设计；框架是面向编程或配置的半成品；组件是从技术维度上的复用；模块是从业务维度上职责的划分；系统是相互协同可运行的实体。 架构设计的目的 明确“架构设计是为了解决软件复杂度”原则后 “这么多需求，从哪里开始下手进行架构设计呢？” — 通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计。 “架构设计要考虑高性能、高可用、高扩展……这么多高 XX，全部设计完成估计要 1 个月，但老大只给了 1 周时间” —架构设计并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出复杂点然后有针对性地解决问题。 “业界 A 公司的架构是 X，B 公司的方案是 Y，两个差别比较大，该参考哪一个呢？” —理解每个架构方案背后所需要解决的复杂点，然后才能对比自己的业务复杂点，参考复杂点相似的方案。 其次，遵循这条准则能够让“老鸟”架构师有的放矢，而不是贪大求全。技术人员往往都希望自己能够做出最牛的东西，架构师也不例外，尤其是一些“老鸟”架构师，为了证明自己的技术牛，可能会陷入贪大求全的焦油坑而无法自拔。 例如：“我们的系统一定要做到每秒 TPS 10 万”。 “淘宝的架构是这么做的，我们也要这么做”。 “Docker 现在很流行，我们的架构应该将 Docker 应用进来”。 以上这些想法，如果拿“架构设计是为了解决软件复杂度”这个原则来衡量，就很容易判断。 “我们的系统一定要做到每秒 TPS 10 万” —如果系统的复杂度不是在性能这部分，TPS 做到 10 万并没有什么用。 “淘宝的架构是这么做的，我们也要这么做” —淘宝的架构是为了解决淘宝业务的复杂度而设计的，淘宝的业务复杂度并不就是我们的业务复杂度，绝大多数业务的用户量都不可能有淘宝那么大。 “Docker 现在很流行，我们的架构应该将 Docker 应用进来 —Docker 不是万能的，只是为了解决资源重用和动态分配而设计的，如果我们的系统复杂度根本不是在这方面，引入 Docker 没有什么意义。 ...