编程小白到架构师的进阶之路（附学习资料）

序言

在从编程小白到架构师的修炼过程中，所需要学习的知识是非常庞杂的。

我最开始学习架构设计的时候，一直搞不清楚系统如何实现从无序到有序，网上也找不到系统的资料。

这里整理了这些年关于架构设计的知识储备，给一些刚迈入架构师或想要进入架构师行业的同学，一点点参考（内容会逐渐深入）。

一、什么是架构设计？

所谓架构设计，就是用于指导大型软件系统各个方面的设计。而架构师要做的，就是用最小的人力成本满足需求开发和需求变更，用最小的运行成本来保障软件的运行。

常用的方法有：

1.使用微服务架构，把复杂系统拆分成一系列小的服务，再拆成功能模块，让人员更好地分工协作

2.前后端分离，让程序员专注某个知识领域，降低开发难度

3.分层设计，隔离业务逻辑，减少需求变更带来的影响

二、为什么需要架构设计？

原因无他，就是复杂。

1.需求让技术变复杂。小网站与大网站的技术复杂度不是一个等级，想想你自己搭建的个人站和谷歌网站的差别；

2.人员让技术复杂。成员水平不等、擅长技术也不一样，有效协作是考验；

3.技术本身复杂。使用的语言、框架、组件、数据库、大数据等技术，都有学习成本

4.软件稳定运行也复杂。软件上线并不是软件项目的终点，那才是真正考验的开始，因为充满了各种不确定性。比如某明星发个微博可能造成系统瘫痪，又比如有人删库跑路了（参考年初某盟的删库事件）。

正因为存在以上原因，我们才需要架构设计去降低这些复杂性，进而降低开发成本、提升协作效率、保障服务稳定运行。

三、如何做好架构设计？

一般分为四步：

1.分析需求。对产品的需求进行抽象，分析用例，了解各种用户角色和其使用的场景。这是后续工作得以实施的大前提。

2.选择相似的成熟架构设计方案。例如我们前面提到的，微服务架构、前后端分离、分层设计等。

3.自顶向下层层细化。好的实践是自顶向下的，不过早陷入技术细节中，从整体到局部规划，设计好部署架构、分层和分模块、API设计、数据库设计等。

4.验证和优化架构设计方案。这个是贯穿整个设计始终的，一个完整的架构设计方案，是需要有多次的评审，收集多方反馈，反复修改后确定的。

四、总体架构设计分类

1.单体架构

适用场景：适合小项目，用户数，业务处理还比较简单，一两台服务器能支撑起正常的业务处理。

优点：开发简单直接，集中式管理；基本不会重复开发；功能都在本地，没有分布式的管理开销和调用开销

不足：开发效率低、代码维护难、部署不灵活、稳定性不高、扩展性不够

2.水平分层架构

单体架构进行水平拆分，就形成了水平分层架构。水平分层是基于功能性的。

适用场景：需要快速构建的新应用程序，需要严格的可维护性和可测试性标准的应用

优点：降低系统的复杂度，同时满足单一职责、高内聚、低耦合、提高可复用性和降低维护成本

缺点：分层过多会导致请求路径变长、平均响应延迟变高、定位问题变的复杂化、运维成本增加

3.面向服务架构（SOA）

SOA架构，即面向服务架构，是单体架构垂直拆分的结果

适用场景：适合于庞大、 复杂、异构的企业级系统

优点：更易维护、更高的可用性（低耦合）、更好的伸缩性

不足：每个服务还是单体架构，对ESB严重依赖

4.微服务架构

微服务架构即按照水平方向去拆分，又按照垂直方向去拆分。

适用场景：适合于快速、轻量级、基于Web的互联网系统，这类系统业务变化快，需要快速尝试、快速交付。

优点：服务颗粒度更细，有利于资源的重复利用，提高开发效率；更加精确制定单个服务的优化方案；加快部署速度

不足：服务划分过细，会导致服务间关系复杂、调用链太长性能下降，问题定位困难；团队效率下降；没有自动化支撑，无法快速交付。

五、分布式架构拆分（实战）

谈了这么多理论，来个实战的（如何拆分分布式架构）。

1.设计module骨架

module骨架的设计是基础，影响最终拆分结果，拆分成功的向导。按照技术，业务，部署打包，测试这几个维度来规划设计，下面是一个参考：

root web app
网关：api-gateway
微服务：pom module、 user-service、order-service，…
业务：biz-user、biz-order
框架：framework
工具类：tools

2.拆分技术commons

分离出技术上的commons，把相关的类重构到一个包里，再分离出一个module。

3.拆分entity

很多在业务代码上都会共享entity类，通常没法也没法把entity类分门别类，最简单就是把所有的entity类放到一个module，谁需要谁依赖的原则。

4.公共业务

同commons和entity方法，不再赘述。

5.拆分业务代码

一般有2种方法（也是从其他大佬里参考的）：

新建业务module，加入基础module的pom依赖，再从源module复制和该业务module相关的代码（包括单元测试代码）过来，解决编译错误和单元测试错误，完成本业务拆分。

从源module复制一个新业务module，保持代码一致，先删除和本义务无关的代码（包括单元测试代码），再删除无关的pom依赖，解决编译错误和单元测试错误，完成本业务拆分。

选择哪种方法，可以根据代码整洁度和互相依赖程度，如果代码很整洁且相互依赖较弱，可以采取前者，否则就采取后者。

6.拆分微服务

有了以上的拆分基础，可以在合适的业务迭代将各个微服务module迁移到不同的代码仓库，完成进一步隔离管理。

---

以上只是架构设计必备知识的冰山一角，还有更多系统的知识点，比如mybatis架构、Android架构、RPC框架设计等，都可以在我收藏整理的这个思维导图资源包里找到。