当我们提到架构的时候，架构到底是什么？
建筑工人造楼房时，一定不可能造完了这一层再去想上一层应该怎么造。
建筑师、土木工程师早就在地基打好之前就已经把这个建筑的结构设计好了。
<!--more-->
架构到底是什么？
当在计算机或者互联网领域提架构的时候，我们更多的是在聊业务架构。简而言之，每一个业务中都有一些实体，这些实体之间有一些关系，这些关系是为了完成业务的需求而存在的，而架构就是考虑清楚这些实体之间的关系。用一个更专业的名词来讲，领域模型。
一个很简单的例子：
当我们去设计一个博客系统的时候，我们的实体主要有：文章、标签、分类。一个文章是否可以属于多个分类？一个分类下是否有多个文章？标签和分类有没有关系？
这些其实没有一个明确的答案，真正的答案是业务需求告诉你的。
因此，一个好的业务架构的设计离不开靠谱的产品经理，产品经理的PRD里应该将这些表述确定清楚。而技术人员在设计技术方案的时候，也首先要先将产品的PRD完全吃透，并提炼出领域实体之间的关系，才能设计出更合理的业务架构。
而我们今天要聊的架构，主要是技术架构。技术架构与业务架构是完全两件事情，技术架构更多的是关注技术实现，而业务架构更多的是关注业务需求。
技术架构的范围很大，例如一个业务系统的技术架构，可能涉及到数据库、缓存、中间件、消息队列、RPC、服务发现、限流、熔断、监控、链路追踪、部署、运维等等多方面的内容。
那么，我们再回到主题，什么样的架构是好架构？
我们再引入一个名词，架构的腐朽。任何架构都会面临随着时间的演进，人员的流动而腐朽，因此，在不同的业务阶段，去逐渐的演进架构，是非常重要的。
以单体架构来讲，在今天，我们看到单体架构往往是带着批判的角度去聊。单体架构固然有各种缺点，但是在业务初期尤其是初创团队人员比较紧张的时候，单体架构是最好的选择。一上来就搞微服务架构，搞K8S，试问初创团队有这么多专业的人手么。业务系统依赖还比较简单的时候，由于技术架构的设计使得大家之间的调用成本变高，不见得是一件好事。
但是随着时间的变化，这些单体应用必然就会带来困境。如果不进行拆分，许多人都维护一个应用，不仅会带来代码上频繁的冲突，在构建发布的过程也是会牵一发动全身。
所以，完美的架构是不存在的。但是，我们的设计一定要有一定的前瞻性。例如我们现在选择了一个单体架构，但是我在代码分层上做了很多思考。在后续面临瓶颈的时候，我们可以将单体应用拆分成多个应用，每个应用都有自己的职责，职责明确。
讲了这么多，又感觉啥都没讲。架构这个命题确实比较虚，我想表达的观点是：在计算机领域，完美的解决方案并不存在，但技术设计一定要对未来有一定前瞻性设计。