接上篇文章，这篇文章聊聊技术同学如何由点及面的了解并掌握系统架构知识。
大家可以先回想一下，我们入职一家新公司做技术工作，一般都是如何开展工作的。
首先，我们需要了解团队和项目的技术规范和迭代发布上线流程。其次，还要了解自己所在岗位负责哪些业务，对应的沟通合作对象是谁。
再次，还需要将项目代码下载到本地，进行代码走查熟悉代码和相关逻辑。如果是测试同学，一般会从最近几个版本的需求和测试用例入手，对自己负责部分和模块边界有大致的了解。
最后，最好是review一下最近线上出现的一些问题和历史版本比较严重的线上故障，对其背后的根因和覆盘优化方案做进一步了解。
总结一下，就是从流程+业务+代码(用例)+线上问题四个维度，对自己即将开展的工作进行全面了解。换个角度，要了解并掌握系统架构知识，也可以从这几个维度来展开。
其中研发规范和迭代发布流程属于通用部分，虽然在不同公司稍显差异，但整体大差不差，这里不展开介绍。
本文以测试岗位视角(假设入职一家新公司，主要负责订单模块的测试工作)，为大家介绍如何从业务、技术和线上问题三个方面来了解系统架构基础知识。
订单业务主要包含如下几个部分：
即正向流程(创建订单)和逆向流程(取消订单)，以及延伸的如订单列表、订单详情。
但仅仅了解订单的业务逻辑是不够的，因为订单业务有很多上下游依赖部分，比如营销增长业务的优惠券和各种活动，比如订单支付涉及到的三方支付，比如库存和供应链业务的物流信息等。
与这些依赖业务对应的，则是不同的业务服务，以及服务间的调用关系。如果你不了解这些，测试过程中遇到报错，你都不知道问题根因是什么，提BUG都显得底气不足。
再进一步，了解了订单业务和其上下游依赖之外，还可以了解整个的业务流，即我们所说的端到端测试，如下图。
接着从技术角度来展开分享。
如图一所示，要对订单应用展开接口测试，那我们势必要了解订单服务的接口定义，请求入参的各项Key对应的Value是什么，分别是调用哪个业务应用获取到的数据。
创建的订单数据是否落库(表结构/对应字段)，是否命中缓存(秒杀业务)，订单状态是否正确变更(支付成功)，APP是否有正常的消息推送(调用push服务或者notice服务)。
除了上述内容，还要考虑用户下单时的登录验签是否通过。如果订单应用请求报500的状态码，就要检查请求的URL是否正确或者服务是否启动并注册成功(注册中心和配置中心)。
如果请求报错，就要根据报错内容判断是否是其他依赖应用未启动或者参数有误(查看日志)。如果是很复杂的一个依赖调用关系，还需要借助链路追踪(Trace)来定位请求的哪个环节出了问题。
有些业务不要求数据的实时一致性，在测试时还要查看消息队列，验证订单消息的生成和消息状态。
结合业务和技术，并加以梳理和总结，就可以对系统架构有大致了解。如下图所示，是一个简易的微服务系统架构图：
第三部分，从线上问题的角度来展开分享。
为什么要提到线上问题呢，主要原因有这几个方面。首先，大部分线上问题都是由于发布和线上变更导致的。
其次，引起线上问题的因素很多，因此需要建立完善强大的线上监控体系；最后，线上问题发生后的修复和覆盘优化，也是深入了解系统架构细节很好的一个方式。
要降低线上问题出现的频率和影响范围，就涉及到稳定性保障领域。在稳定性保障中，比较好的技术实践有全链路压测、混沌工程，而这些技术实践都涉及到很广泛的业务，以及技术细节。
要快速发现并修复线上问题，需要很好的监控工具，而好的监控工具一定是以业务稳定性为出发点，并涉及到很多的技术细节，如下图所示。
且线上问题背后隐含着一个很重要的因素，即线上的业务防资损。要做好业务防资损，同样需要对业务有深入的理解，并且要从系统整体架构层面来进行优化预防。
最后总结一下，要由点及面的了解并掌握系统架构知识，可以从如下三个角度切入：
- 从业务角度，了解端到端业务流，背后的业务模块，对应的服务调用关系。
- 从技术角度，数据输入输出，依赖谁，被谁依赖，为什么报错，日志排查。
- 从线上问题角度，监控体系，业务防资损，故障覆盘优化。
结合这几个方面，在日常工作中多梳理总结，就可以对系统架构有基础的了解和掌握。