什么是架构

架构是一系列高层次的设计决策，用来平衡系统在功能与非功能上的需求。

这句话包含几个关键点：

1. 高层次决策：架构并不是细枝末节的代码实现，而是决定系统整体形态的核心选择。例如，选单体还是微服务？数据存储用关系型还是 NoSQL？
2. 功能需求：满足业务逻辑，能“做对的事”。
3. 非功能需求：性能、可扩展性、可维护性、安全性、可靠性等。往往这些是架构师最需要权衡的部分。
4. 平衡：没有完美的架构，所有决策都伴随取舍（trade-off）。比如，高一致性往往牺牲性能，高性能有时会降低可维护性。

为什么需要架构

很多同学在开发的时候，会觉得“直接写就好了，为什么要架构？”——但当系统复杂度越来越高时，架构的意义就越来越重要了。 架构存在的意义是当系统越来越复杂的时候，让整个系统依然可控。

1. 应对复杂度：一个单体项目，可能最初只有几千行代码，但快速膨胀到几十万行时，如果没有架构设计，任何一个小的改动都可能牵一发而动全身。
2. 保障非功能性：业务逻辑可以用代码写出来，但性能、稳定性、扩展性则需要从一开始通过架构来设计。
3. 团队协作：架构为团队提供了统一的“蓝图”，让不同的人能够在同一套框架下协作，而不至于各自为政。

师父是目标——必须保到西天；
我呢，能打妖怪——保证性能和安全；
你负责挑担子——搬数据、搬逻辑；
沙僧是运维，保证大家饿不死、渴不着。
这就是一个架构设计：分工明确、职责清晰、能扛事儿。

三个层次的架构

1. 宏观架构（系统层）
   • 例子：单体架构、SOA、微服务、Serverless
   • 决策：系统如何划分模块，如何通信，整体运行方式是什么。
2. 中观架构（子系统层）
   • 例子：服务如何分层（Controller-Service-DAO），缓存如何接入，数据库如何分库分表。
   • 决策：模块之间如何依赖，数据流与调用链如何组织。
3. 微观架构（组件层）
   • 例子：如何处理日志，如何做鉴权，如何保证幂等性。
   • 决策：某个组件或模块的内部设计。

好的架构不是完美的架构，而是合适的架构——合适业务阶段、合适团队规模、合适未来演进方向。作为架构师或开发者，面对架构时需要具备以下思维：

1. 需求导向：架构不是炫技，而是为了解决实际问题。
2. 权衡取舍：在性能、成本、可维护性、安全性之间找到平衡。
3. 演进思维：系统初期可能是单体，后期逐渐服务化，最后再分布式。不要一开始就追求“大而全”。

架构不是抽象的空谈，而是指导我们如何在复杂系统中做出清晰、高层次的决策。它既关乎技术选择，也关乎团队协作和业务发展。

喜欢本文的朋友们，欢迎大家关注我~