架构篇（二）架构的复杂度来源

上一篇我们谈到，架构的本质就是解决业务和技术变化带来的复杂性。

那这一篇我们来谈一下复杂性到底来自于哪里。

业务复杂性

系统首先要满足当前的业务需求，在此基础上，还要满足将来的业务需求，因此系统要能不断地扩展变化，包括调整现有功能，以及增加新功能。

而且，系统的功能变化不能影响现有业务，不要一修改，就牵一发动全身，到处出问题。因此，在架构设计上，要做到系统的柔性可扩展，能够根据业务变化做灵活的调整。

此外，市场不等人，上新业务要快，之前花了半年上了个业务，这回再上个类似的新业务，需要短时间就能落地。因此，架构设计上，还要做到系统功能的可重用，这样才能通过快速复用，实现业务敏捷和创新。

技术复杂性

要保证一个业务能正常运行，除了满足业务功能之外，还要保证这个系统稳定可用。

一个复杂系统是由很多部分组成的，如应用程序、服务器、数据库、网络、中间件等，都可能会出问题。那怎么在出问题时，能够快速恢复系统或者让备用系统顶上去呢?

还有流量问题，平时流量不大，少量机器就可以处理，但在大促的时候，大量流量进来，系统是不是能够通过简单地加机器方式就能支持呢?

此外还有低成本的问题，系统能否做到，使用廉价设备而不是高大上的IOE设备，使用免费的开源组件而不是昂贵的商业套件，使用虚拟化技术而不是物理机，并且在流量低谷和高峰的不同时期，让系统能够弹性缩容和扩容呢?

因此，一个好的架构设计既要满足业务的可扩展、可复用;也要满足系统的高可用、高性能和可伸缩，并尽量采用低成本的方式落地。所以，对架构设计来说，技术和业务两手都要抓，两手都要硬。