架构设计到底是什么？

架构设计，是中高级研发工程师逃不开的一环，也是成为架构师的关键。

那到底什么是架构设计。

从概念来说比较宽泛，也不容易理解，这时候可以转换方向

利用分类思想，架构设计包括哪些主要内容呢

不断堆积调查研究材料，不断丰富我们的主题。

• 架构原理
• 分布式技术
• 中间件
• 数据库
• 缓存
• 业务系统架构

以上6个模块就比较完整地说明架构设计是什么？

架构设计有哪些内容？

架构原理与技术认知

以架构师视角解析研发在遇到系统设计问题时，应具备怎样的技术认知和解题思路。架构设计的底层思维逻辑是你的架构设计能否立足的根本，决定了你在面试时从什么角度来回答提问才更有价值

分布式技术原理与设计

有一句话叫“不懂分布式，别来面试互联网”， 通过亿级商品的数据存储问题，解析在分布式系统技术架构中，面对热点问题该如何回答，比如用 etcd 如何解决数据共识问题？

中间件常用组件的原理和设计问题

讲解 RPC 远程调用和MQ（消息队列）的技术原理和实践，比如如何实现一个 RPC 框架？MQ 如何实现消息的不丢失、不重复消费，以及积压等问题。

数据库原理与设计问题

需要掌握 MySQL，架构设计中有一套的 MySQL 知识体系

分布式缓存原理与设计问题

仅能熟练地使用 Redis 还不够，还要求能深入理解底层实现原理，并且具备解决常见问题的能力（尤其是在高并发场景下的缓存解决方案），结合分布式缓存的原理，并结合电商场景下 Redis 的设计案例解锁经典问题。

互联网高性能高可用设计问题

会针对当系统遭遇百万并发时的技术瓶颈，以及优化思路，必问的高性能、高可用问题背后的原理，比如如何判断你的系统是高可用的？并最终通过电商平台案例。

---

技术认知

互联网公司会把技术层层设卡，通过架构设计上的各类知识点将研发工程师进行分层。但是每个人的工作经历有限，很多人遇不到好的平台和好的机会，在平时工作中只做着 CRUD 的工作，这个问题对于很多中小型企业的研发工程师尤为明显，就导致他们应聘大厂的竞争力偏弱。

作为一名技术人，我们既然选择了这个职业，就一定要有上进的决心，不能只顾写代码，一定要提升架构设计能力。因为即使代码写得再好，做的也是执行层面的事儿，就会有收入的天花板，想要突破它，就要突破你做事儿的边界，让自己成为一个架构师或技术负责人。而这些内容对于从事 IT 开发工作的你，越早知道越好

上进为架构师，这离不开“从学习到分享再到学习”的一个迭代过程。

架构分析

关于架构设计的问题，一定要立足于点、连接成线、扩散成面

为什么还要做系统架构拆分？而且拆分之后会带来其他的复杂度，你是怎么考虑的？

系统拆分的架构设计问题，在面试中很常见，候选人给出了四个层面的回答。

• 从订单系统层面来看，由于交易流程中的订单系统相对来说业务稳定，不存在很多的迭代需求，如果耦合到整个交易系统中，在其他功能发布上线的时候会影响订单系统，比如订单中心的稳定性。基于这样的考虑，需要拆分出一个独立的子系统。

• 从促销系统层面来看，由于促销系统是交易流程中的非核心系统，出于保障交易流程稳定性的考虑，将促销系统单独拆分出来，在发生异常的时候能让促销系统具有可降级的能力。

• 从报价系统层面来看，报价是业务交易流程中最为复杂和灵活的系统，出于专业化和快速迭代的考虑，拆分出一个独立的报价系统，目的就是为了快速响应需求的变化。

• 从复杂度评估层面来看，系统拆分虽然会导致系统交互更加复杂，但在规范了 API 的格式定义和调用方式后，系统的复杂度可以维持在可控的范围内。

系统设计的思考与理解。原有系统中关于订单、促销和报价功能耦合在一起带来的实际问题，这是立足于点，又从交易流程的角度做系统设计串联起三个系统的拆分逻辑，这是连接成线，最后从复杂度和成本考量的方向夯实了设计的原则，这是扩展成面。

问题分析

在实际工作中，技术人员在做系统设计时需要与公司或部门的战略定位对齐，才能让你的技术有价值。因为对于系统技术架构升级的问题，业务方、管理者和技术人员的关注点是不同的。

• 业务方的诉求是在技术升级后，系统有能力迭代功能来满足市场的要求，所以关注点在系统能力。
• 管理者的诉求是在技术升级后，系统研发团队的开发效能得到提升，所以关注点在人效管理。
• 作为技术人员的你，需要找到自己做系统设计的立足点，来满足不同人对技术的诉求，而这个立足点通常就是系统设计原则。

所以你应该认识到，系统的设计原则不是乱提出来的，而是针对系统现阶段业务发展带来的主要矛盾提出，才会更有价值且被认可。

其实做任何事情都是这样的，抓主要矛盾。

案例

之前我做过一个对原有老系统进行架构改造的系统设计，当时的背景是这样的。

早期，业务发展比较简单，团队规模也不是很大，单体系统可以支撑业务的早期规模，但当业务不断发展，团队规模越来越大时，之前的一个业务团队逐渐发展成了多个业务团队，这时每个业务团队都会提出自己的功能需求。

然而，系统现状仍然是单体架构，研发同学都在同一个系统里进行开发，使得系统逻辑复杂，代码耦合，功能迭代和交付变得非常缓慢，牵一发而动全身，研发同学都不敢轻易修改代码。

这个时期系统的主要矛盾就变成了：多人协作进行复杂业务，导致速度缓慢，但业务需求又快速迭代。说白了，就是研发效率不能匹配业务发展的速度，并且单靠加人不能解决问题。

对于这样的一个系统，此阶段的系统架构核心原则就不能随便定义为要保证高性能和高可用。

那么应该怎么做呢？针对这样的问题，我们需要对原有系统进行合理的系统边界拆分，让研发人员有能力提速，来快速响应需求变化，这就要求架构师对业务领域和团队人员有足够的了解。

类似这样的情况也是面试中经常出现的考题，比如面试官在问你历史项目经历的时候，要重点关注你是如何解决系统核心问题的，所以不要一张口就是高性能、高可用，这会让有经验的面试官觉得你很初级。

软件复杂性来源于两点：本质复杂度和偶然复杂度。开发工具、开发框架、开发模式，以及高性能和高可用这些仅是偶然复杂性，架构最重要的是要解决本质复杂性，这包括人的复杂性和业务的复杂性。

技术是静态的，业务和用户是变化的，具体问题要从具体的业务领域出发。这时有人可能会说，我只想做技术，不想做业务，然而你会慢慢发现，在职业生涯中处理的最有价值的事情，一般都是利用技术解决了业务领域的某阶段的主要问题，这也是最复杂的。

具体问题具体分析，实事求是，这是做事的指导方针。

能力边界

一个高级研发工程师和一个架构师的区别在哪？ 这个问题很多研发同学回答得都不是很好，有些人说需要足够的技术经验，懂得高性能、高可用，也有些人说需要懂得管理，带过团队。

这些能力固然重要，但不是作为架构师最核心的能力。下面我通过一个例子，来帮你理解一个高级研发工程师和一个架构师的本质区别在哪儿。

我们常说，屁股决定脑袋，不在那个位置就不会真正体会到那个位置带来的问题。没有触达多系统层面的设计，就不会掌握多系统层面带来的复杂度和解决问题的思考逻辑。但是往往研发同学意识不到这样的问题存在，即便能碰到一个通盘考虑架构设计的机会，但价值、眼界、认知的形成，也不是一朝一夕的事儿。

那么，你要怎么做才能让自己更快速地成长呢？你要在工作中养成归纳总结的习惯，形成自己的知识体系，沉淀自己的方法论，提高自己的认知能力，并且跳出舒适区，多争取扩展自己能驾驭系统的边界的机会。

小结

• 首先要提高你对系统架构设计的认知能力，一个好的架构师的架构设计不是仅仅停留在技术解决方案上。
• 其次要提高你分析系统问题的认知能力，做架构设计要具备根据现阶段的主要矛盾来分析问题的能力。
• 最后你要扩大自己能够驾驭系统的边界，因为只有这样才能遇到之前没经历过的问题层次，注意我这里说的是问题层次，而不是问题数量