系统架构基础知识入门指南 - 上

接上一篇文章《为什么测试要了解系统架构》的内容，这篇聊聊如何掌握基础的系统架构知识。

从我个人的角度来说，所谓的系统架构，就是对软件系统整体结构的抽象设计。如何理解这句话呢？举个生活中常见的例子：如何盖一座房子？正常的做法是先勘探地质，然后对房子进行设计(房屋大小朝向、门窗尺寸用料、预算多少)，最后才是制定对应的施工方案，开工建设。软件的系统架构也可以用类似的角度理解。

换个角度理解，企业为了达成某个商业目标(愿景)，提出了要建设一个软件系统(达成方式)，因此才有了各种各样的业务需求(达成过程的细节)。软件系统是业务需求实现的载体，系统架构是对业务的抽象理解和实现设计，是对软件产品进行分解再组合的过程。通过将软件产品分解为不同的组件、模块，重新组织他们的交互逻辑和链路，最终形成一个软件产品。

从软件研发测试流程的角度来看，业务提出诉求，产品设计需求，研发用技术实现，测试针对系统各功能模块进行验证，最后验收通过发布上线，这个过程和系统架构设计是紧密相关的。

不同的业务需求有不同的分类，比如营销、订单、支付、库存。遇到这些业务需求时，首先要对需求进行识别拆分，即将不同的需求分组到对应的业务模块(谁来负责技术实现)。

其次技术实现要考虑实现的难易成本和业务情况(影响技术选型)，比如初创企业业务量小，需要快速迭代，往往选择 LNMP 全家桶。如果是业务复杂且业务量较大，这个时候选择 Java 全家桶就比较多。

技术实现过程中，要考虑数据存储、代码管理、服务部署和发布，与之对应的就是数据库选型、代码仓库选型、发布系统(或持续集成流水线)构建。

到了测试环节，会用到各种测试方法和工具，这个时候诸如 Postman、JMeter 就开始登上舞台。不同业务模块对应的应用服务之前也会有依赖关系，服务之间的请求交互需要考虑通信协议，于是 HTTP、RPC 框架就要发挥作用了。

为了服务发布上线后更稳定的运行，同时统计各种业务和技术指标，需要完善的监控工具来及时跟踪和发现问题，这个时候诸如 Cat、Jaeger、SkyWalking 等工具组件就开始工作。

还有其他基础的技术平台如运维平台，代码仓库和需求管理平台等，这些都是系统架构设计中需要考虑到的。

如上图所示，其中包含了我们常见的系统架构设计中常见的技术组件和工具。

当然，系统架构设计不仅仅是这些，还有设计模式(如单例模式、工厂模式)，所谓的设计模式其实是一种系统架构设计的指导思想和方法论。

从本质上来说，架构是一种决策，即软件系统如何成型，至于采用何种设计模式指导，选择哪些技术组件则是设计领域。如上图中的编程语言选择、框架选择、各种中间件和基础服务选择，都是设计的一部分。

软件系统架构设计，很重要的一点是搞清楚哪些部分最重要，以及这些重要部分如何实现。

这篇文章是对系统架构基础知识的一个罗列说明，下篇文章，聊聊技术同学如何由点及面的了解并掌握这些知识。