如何快速熟悉一个系统

业务学习

业务学习就是从业务角度去学习系统，我们需要了解系统的客户是谁、使用人是谁、带来了什么价值，系统提供了哪些功能等。

不清楚业务，就等于不知道系统在干什么。技术是为业务落地而服务，清楚了业务才知道怎样用技术更好地服务业务，所以业务学习是熟悉一个系统的首要任务。这块主要的学习方式有跟产品、运营、开发沟通，学习产品设计文档文档、PRD、自己使用系统，还有一些常见图，如产品功能架构图、业务流程图、功能树，用例图等。

技术学习主要学习系统的架构、如何实现、系统的运维等。描述一个系统的架构有五视图方法论。

五视图分别是：

• 逻辑架构
• 开发架构
• 运行架构
• 物理架构
• 数据架构

逻辑架构

逻辑架构着重考虑功能需求，系统应当向用户提供什么样的服务，关注点主要是行为或职责的划分。

常用表达图形，静态图有包图、类图、对象图；动态图有序列图、协作图、状态图、活动图。逻辑架构的核心设计任务是模块划分、接口定义、领域模型细化。

常见问题：

• 有哪些子系统或模块？系统之间是什么样的关系？
• 对外上下游接口有哪些？对接人是谁？
• 关键业务流程怎么实现的？用类图、序列图等方式表达出来。

开发架构

开发架构关主要关注系统源代码、第三方 SDK、使用的框架、中间件、工具包。

常见问题：

• 代码在哪？
• 包怎么划分的？怎么分层？如 mvc、controller-service-dao；
• 用了什么框架，如 ssh、dubbo；
• 用了哪些工具包？如 apache commons、guava；
• 用了哪些中间件？如 metaq、tair、schedulerX、Diamond；
• 依赖哪些平台？如权限平台、流程引擎等。

运行架构

运行架构的着重考虑运行期质量属性，关注点是系统的并发、同步、通信等问题，这势必涉及到进程、线程、对象等运行时概念，以及相关的并发、同步、通信等。

常见问题：

• 系统能支撑多少 qps？峰值 qps 多少？
• 与上下游系统怎么交互的？rpc？http？同步还是异步？

物理架构

物理架构的设计着重考虑安装和部署需求，关注点是目标程序及其依赖的运行库和系统软件最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性、持续可用性、性能和安全性等要求。

常见问题：

• 系统如何发布部署？有哪些部署环境？
• 系统有多少台机器？
• 系统部署怎么部署的？关注接入层，部署方式，如集群部署、分布式部署等
• 有没有容器化？
• 有没有多机房部署？

数据架构

数据架构的设计着重考虑数据需求，关注点是持久化数据的存储方案，不仅包括实体及实体关系数据存储格式，还可能包括数据传递、数据复制、数据同步等策略。

常见问题：

• 数据存储在哪？用了什么数据库，如 oracle、mysql；
• 梳理 E-R 图；
• 数据量有多少？是否有分库分表？
• 用了哪些 nosql 库？
• 有哪些数据同步任务？
• 大数据框架的使用情况如何？

系统运维

系统运维重点关注什么时候会出问题，出了问题怎么解决。
常见问题：

• 什么时间容易出问题？比如电商 双 11，对系统的压力很大，这时候很容易出问题；
• 对关键功能是否有监控？需要看系统有配置了哪些报警项，监控了哪些方面；
• 出了问题怎么解决？日志在哪？是否有全链路跟踪？是否有一些紧急操作，比如开关配置、降级、限流配置；
• 系统有哪些坑？找开发同学回顾历史问题，以免踩坑。通过同事总结的 case，或者与负责的产品、运营、技术与了解。系统总会有一些坑，需要把这些坑填上。历史代码经过多次迭代总会导致复杂度高（分支、嵌套、循环很多），存在设计漏洞，性能隐患等，很难维护，这些就需要我们去重构了。记住有一句话：填的坑越大，能力越大；

运营、客服反馈的常见问题有哪些？

实践

熟悉了系统的业务和技术后，就要实战了，通过实战进一步加深对系统的熟悉程度。实践可以通过做需求、修 bug、重构等方式，亲自动手编码、调试、测试、上线。

总结

已有系统通常经历了从 0 到 N 的建设过程，熟悉系统其实是一个逆向推导过程，也是一个学习架构、阅读源码的过程。
在学习的过程中最好能带上思考，比如为什么要这么设计？为什么要用这个中间件？是否有更好的编码方式？哪些地方可以优化等，以此达到一个深入熟悉的过程。

参考资料

• https://www.infoq.cn/article/lmae2kjtwse0lzmfbhze