什么是架构设计？

由于软件设计是一个复杂度很高的活动，“通过组件化完成关注点分离从而降低局部复杂度”很早就成为了咱们这个行业的共识。前面提到的数据存储、消息管道等“模块”在某种意义上都是组件化的产物。这样的好处是在不同系统里遇到同样的功能需求时可以复用。在云服务崛起的今天，这样的组件以“服务”的形式更容易为我们所采用。

当然技术出身的架构师们在架构设计的时候或多或少都有一种“搭积木”的感觉。大家都非常关注Kafaka有哪些功能，K8S是不是比Mesos功能更全，以及Akka是不是稳定。就像走进一个家装公司，在选择了“套餐”之后有工程人员给你介绍地砖和木地板用哪个品牌更好。

回到咱们的第二个核心痛点，如果只是这样的搭积木，为什么咱们总是在面对新变化、新需求的时候发现需要新的组装方式或新的组件呢？这样的架构设计对比直接按照需求实现（不考虑架构）有什么优势呢？

这里我们应该回到架构设计的本质，即为什么我们要在代码实现前做设计。显然如果去掉设计这个过程，大家会说问题这么复杂，如何下手啊？所以设计首先是要解决问题的复杂度。于是有人做了一个架构，交给了一个团队去实现，很快发现实现的架构和设计完全是两张皮。当然原因很明确——缺少了交流和沟通，所以设计其次是要建立团队协作沟通的共识。

假设我们产生了一个团队都达成共识的架构设计，大家都兢兢业业把设计变成了现实。一个长期困扰软件行业的问题出现了，需求总是在变化，无论预先设计如何“精确”，总是发现下一个坑就在不远处。相信很多技术人员都有这样的经历，结果往往是情况越来越糟糕，也就是我们常说的架构腐化了，最后大家不得不接受重写。这些经历让我们逐步明确了软件架构设计的实质是让系统能够更快地响应外界业务的变化，并且使得系统能够持续演进。在遇到变化时不需要从头开始，保证实现成本得到有效控制。