架构篇(二)架构的复杂度来源

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

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

业务复杂性

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

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

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

技术复杂性

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

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

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

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

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

猜你喜欢

转载自blog.csdn.net/lin819747263/article/details/126233717