架构设计的复杂度来源其实就是架构设计要解决的问题，主要有如下几个：高性能、高可用、可扩展、低成本、安全、规模。复杂度的关键，就是新旧技术之间不是完全的替代关系，有交叉，有各自的特点，所以才需要具体问题具体分析，基于各方考虑设计合适的架构，存在合适的架构，不存在最好的架构。这篇主要讨论低成本、安全、规模的问题。

低成本

当我们设计“高性能”“高可用”的架构时，通用的手段都是增加更多服务器来满足“高性能”和“高可用”的要求；而低成本正好与此相反，我们需要减少服务器的数量才能达成低成本的目标，低成本本质上是与高性能和高可用冲突的，所以低成本很多时候不会是架构设计的首要目标，而是架构设计的附加约束

  1. 我们首先设定一个成本目标，当我们根据高性能、高可用的要求设计出方案时，评估一下方案是否能满足成本目标
  2. 如果不行，就需要重新设计架构
  3. 如果无论如何都无法设计出满足成本要求的方案，那就只能找老板调整成本目标了。

低成本给架构设计带来的主要复杂度体现在，往往只有创新才能达到低成本目标。包括

  • 【大公司】开创一个全新的技术领域（这个要求对绝大部分公司太高），创造新技术的主要复杂度在于需要自己去创造全新的理念和技术，并且新技术跟旧技术相比，需要有质的飞跃
  • 【小公司】引入新技术。引入新技术的主要复杂度在于需要去熟悉新技术，并且将新技术与已有技术结合起来

安全

从技术角度看，安全可以分为功能安全和架构安全两大类：

  • 功能安全：主要与具体编码相关，架构设计中的关联较小。目前许多开发框架都内置了常见的安全功能，减少了重复开发安全模块的工作量。
  • 架构安全：传统上依靠防火墙来实现。防火墙通过将网络划分为不同区域，并制定区域间的访问控制策略来控制数据流，从而实现网络的隔离和保护。

规模

规模带来复杂度的主要原因就是“量变引起质变”，当数量超过一定的阈值后，复杂度会发生质的变化。常见的规模带来的复杂度有

  1. 功能数量的增加：当系统功能逐渐增多，系统的复杂度会随着功能之间的交互而指数级上升。可以用以下公式来衡量：系统复杂度 = 功能数量 + 功能之间的连接数量。
  2. 数据量的增加：随着数据的增长，系统的复杂性会发生质变。以MySQL为例，单表的最优数据量因业务场景不同有所差异，但通常建议在5000万行左右进行优化，避免性能瓶颈。

总结

低成本与高性能、高可用存在内在冲突，因此通常不会作为架构设计的首要目标，而是附加约束。功能安全通常由框架提供，架构安全一般依赖运营商或云服务商来实现。随着业务的扩展，规模会带来系统复杂性的急剧上升，扩展性不好的架构会随着业务升级带来更多挑战。因此，在架构设计时，必须确保架构具备良好的扩展性，并在业务规模扩大时及时进行优化调整。