架构设计的复杂度来源其实就是架构设计要解决的问题，主要有如下几个：高性能、高可用、可扩展、低成本、安全、规模。复杂度的关键，就是新旧技术之间不是完全的替代关系，有交叉，有各自的特点，所以才需要具体问题具体分析，基于各方考虑设计合适的架构，存在合适的架构，不存在最好的架构。这篇主要讨论低成本、安全、规模的问题。
低成本
当我们设计“高性能”“高可用”的架构时，通用的手段都是增加更多服务器来满足“高性能”和“高可用”的要求；而低成本正好与此相反，我们需要减少服务器的数量才能达成低成本的目标，低成本本质上是与高性能和高可用冲突的，所以低成本很多时候不会是架构设计的首要目标，而是架构设计的附加约束
- 我们首先设定一个成本目标，当我们根据高性能、高可用的要求设计出方案时，评估一下方案是否能满足成本目标
- 如果不行，就需要重新设计架构
- 如果无论如何都无法设计出满足成本要求的方案，那就只能找老板调整成本目标了。
低成本给架构设计带来的主要复杂度体现在，往往只有创新才能达到低成本目标。包括
- 【大公司】开创一个全新的技术领域（这个要求对绝大部分公司太高），创造新技术的主要复杂度在于需要自己去创造全新的理念和技术，并且新技术跟旧技术相比，需要有质的飞跃
- 【小公司】引入新技术。引入新技术的主要复杂度在于需要去熟悉新技术，并且将新技术与已有技术结合起来
安全
从技术的角度来讲，安全可以分为两类：一类是功能上的安全，一类是架构上的安全
- 功能安全更多地是和具体的编码相关，与架构关系不大。现在很多开发框架都内嵌了常见的安全功能，能够大大减少安全相关功能的重复开发
- 传统的架构安全主要依靠防火墙，防火墙最基本的功能就是隔离网络，通过将网络划分成不同的区域，制定出不同区域之间的访问控制策略来控制不同信任程度区域间传送的数据流
规模
规模带来复杂度的主要原因就是“量变引起质变”，当数量超过一定的阈值后，复杂度会发生质的变化。常见的规模带来的复杂度有
- 功能越来越多，导致系统复杂度指数级上升：假设系统间的功能都是两两相关的，系统的复杂度 = 功能数量 + 功能之间的连接数量
- 数据越来越多，系统复杂度发生质变：MySQL 单表的数据因不同的业务和应用场景会有不同的最优值，但不管怎样都肯定是有一定的限度的，一般推荐在 5000 万行左右
总结一下
低成本本质上是与高性能和高可用冲突的，所以低成本很多时候不会是架构设计的首要目标，而是架构设计的附加约束；安全一般接触不到，功能安全一般框架保证、架构安全一般运营商以及云服务保证；规模其实代表的是业务复杂度的上升对架构的挑战，其实扩展性不好的架构其规模复杂度往往也会随着业务不断升级，所以需要设计扩展性好的架构并且在预测到业务计算及数据规模可能影响正常业务的时候及时进行架构优化。
