如何快速熟悉业务系统

“我报名参加金石计划1期挑战——瓜分10万奖池，这是我的第1篇文章， 点击查看活动详情”

作为开发人员在工作中，最常见遇到以下问题：新人入职需要学习已有系统，被调到新的项目组参与陌生的系统迭代，维护一个离职同事负责的系统等等。这些都是工作中避免不了的难题，那么我们应该怎样快速应对这些场景呢。我觉得主要应该从两方面入手，主要分为业务学习和技术学习。然后再结合工作中的实际项目案例来进行细分拆解，梳理常见问题以及应对方法。

业务学习

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

常见问题：

• 系统所在行业的情况是怎样？
• 系统的目标用户是谁？比如是给公司高层做决策用？给运营或客服用？还是互联网用户用？
• 平均有多少人在使用？高峰期有多少人在用？
• 系统有什么业务价值？有哪些指标可以衡量系统业务价值？
• 系统有哪些功能模块？
• 系统有哪些领域概念？梳理下系统的领域模型；
• 系统的关键业务流程有哪些？关键业务流程是怎样？
• 系统的非功能性需求有哪些？如性能、质量、扩展性、安全性等；
• 系统未来的发展规划是怎样？

以企业短信平台为例

业务分析

1.1 背景

“【xxx】您的验证码是xxx（有效期5分钟）”。

上述验证码短信已经让我们习以为常，然而这只是企业短信最为常见的一个场景。

企业短信服务旨在解决企业运营过程中的信息传递与交流沟通问题，从传统的本地部署模式到如今基于云计算技术理念和服务模式提供的企业级云短信，云计算的资源共享、弹性扩展等特点充分发挥了企业短信降本增效价值和灵活扩展价值，进一步降低了企业接入门槛。

短信属于运营商业务，基于运营商资源的短信是企业在信息触达用户过程中所使用的最传统的通讯方式。而运营商签发的短信通道质量决定了短信质量，如到达率、到达时间等指标，不同运营商所签发的通道号码可以根据前面几位数字区分。

例如：

全网通道：「1069xxx」 移动通道：『10657xxx』 联通通道：『10655xxx』 电信通道：「10659xxx，020xxx，0760xxx，0769xxx」 不同通道又大致分为三种模式：固定独享通道、固定共享通道和随机共享通道。

以上，企业短信仍然属于高增长且高频业务，云计算厂商希望借力于短信的高频属性，将其打造为自身其他云业务的客户切入点和场景延伸，于是纷纷布局短信市场。同时利用自身平台优势接入多家短信代理商从而打造融合短信，最终通过负载均衡实现最优化调度

1.2 应用场景

严格意义上，新一代短信包含了文本，语音和视频短信，而默认短信为文本短信。

随着电话实名制的推行，手机号码已经被视为判断用户真实身份的关键依据，据工信部2017年发布的消息，全部电话用户均实现实名登记。因此，短信业务再度崛起，在身份验证和服务登陆场景下扮演着重要的角色。

文本短信主要分为短信通知、短信验证码和短信推广三大类。短信通知如物流、付款和登陆通知等等，验证码如注册、身份验证等，推广主要是通过活动进行用户唤醒和召回等等。

尽管语音短信有着低效和单价昂贵等缺点，且需要通过语音电话拨号的方式向用户传达信息导致用户抗拒，但是其到高达率以及防刷量等特性也让其成为了文本短信的有效补充

2.1 厂商分析

这里简单将短信厂商可分为两类，第一类是以短信为主营业务的厂商，这类企业营业额90%以上来源于短信业务，第二类是综合云短信厂商，其短信业务更多是作为场景延伸和生态完善。

第一类主要是梦网、大汉三通、创蓝253和云片等单一短信场景厂商，第二类是阿里云、腾讯云、七牛云、华为云、百度云和金山云等综合公有云厂商。

2.2 盈利模式

国内企业短信服务厂商盈利主要来源于两点：运营商酬金（返利）和进销差价。

• 运营商酬金（返利）：主要是指B端客户和运营商签约，采用代理商平台进行短信发送，按发送额获得运营商一定比例酬金；
• 进销差价：从运营商处批量采购短信，并转售给下游企业客户

上图为企业短信厂商产业链，可以看得出，运营商对于下游企业的强主导性，而第三方短信厂商间最关键的竞争要素在于能否掌握质优价廉的运营商资源。

2.3 短信客户选择因素调研

根据赛邮的一份公开调查数据表明，B端客户选择企业短信厂商最看重的两大因素分别是短信及时性&送达率和安全性。

而这两点也和目前企业短信主要用途是业务验证码有关，无论是身份验证和服务登陆都和B端客户业务数据息息相关。

目前业内各大短厂商官方宣称送达率普遍在95%以上，5秒内可达。

3.1 竞品比较

根据尼尔·博登提出的经典4P营销理论，产品（Product）、价格 (Price)、渠道(Place)和促销(Promotion)，价格和产品是决定市场接受度的核心因素。

这里由于某些限制无法得出产品质量（短信及时性&送达率和安全性），仅从价格侧略作分析。

由上图总结，以官方报价模式中，综合云短信厂商整体价格更具优势，这也符合综合云厂商对于企业短信的定位，将其视为自身业务的延伸以增加客户粘度。

而如七牛云新兴企业短信服务商更是在活动中将单价拉到了0.023元/条。

3.2 功能对比

各厂商企业短信功能趋于同质化，最核心的功能即发送短信，完成这个步骤需要创建签名和模板，然后根据签名和模板发送短信。

由于单一短信厂商大部分需要企业认证，无法作进一步分析，上图数据仅包含综合云短信厂商。

得益于媒介的发展，企业信息触达用户的手段也日益丰富，甚至于由短信和语音长期垄断格局被打破，如更多的企业希望通过社交工具代理代替短信营销。不可否认，客户服务与社交媒体的边界正在变得模糊。

然而对于某些特殊场景如身份认证和服务通知等，企业短信仍然是最佳选择。而对于云短信服务商而言，如何将自身短信业务从售前到转换甚至到流失后的召回从而覆盖客户服务全生命周期是一个值的深思的问题。

而且短信业务通过进销差价实现盈利，短信通道的质量很大程度又取决于运营商，所以各大企业短信厂商的核心竞争点在于掌握质优价廉的通道从而薄利多销。

技术学习

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

五视图分别是：

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

逻辑架构

逻辑架构着重考虑功能需求，系统应当向用户提供什么样的服务，关注点主要是行为或职责的划分。常用表达图形，静态图有包图、类图、对象图；动态图有序列图、协作图、状态图、活动图。逻辑架构的核心设计任务是模块划分、接口定义、领域模型细化。

常见问题：

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

企业短信服务为了满足不同的使用需求，功能框架可分为以下5个模块：

• 普通用户：提供了短信发送、短信记录、账单查询、数据统计、账户管理、账户设置等功能，方便了不同用户群体的基本需求
• 运营管理：提供短信管理、运营管理、财务管理、监控管理、系统管理等，为了方便运营人员查询，配置，监控的操作
• 应用程序：按功能划分，主要分为定时任务、网关程序、推送程序、同步程序
• 数据中心：使用Oracle/Mysql进行持久化数据，数据库划分为四种，业务库、网关库、短信队列库和状态报告库
• 基础服务：整个应用程序的基础环境，包含服务器、网络传输、数据存储等，保障了应用的稳定运行

短信平台具备功能：短信管理、数据统计、运营管理、监控管理、财务管理、系统管理等功能

缓存服务

单机部署：可以通过直接使用内存队列来缓存页面及接口传递的短信数据，通过单线程获取内存队列数据批量持久化到数据库中，同时为防止应用因为各种因素导致服务挂掉，使用了JVM的shutdown hook进行序列化到磁盘中，当启动项目时，会重新加载序列化到磁盘的文件。

分布式部署：使用Redis作为缓存中间件

平台核心数据流转

API核心功能实现

1.所有业务系统调用接口、所有校验：账户合法性、号码合法性、内容合法性、发送时段等配置全在内存进行，没有进行任务DB操作 2.校验完毕后，进行计费，在这里如果要求控制配额需要进行一次DB操作，若不需要则不需要操作DB 3.计费完毕后直接把群发或单发的短信直接放入内存组件，然后直接返回客户端本次提交短信结果，响应毫秒级 4.API使用单独的线程从内存队列取数据批量入库，异步处理

网关核心功能实现

1.短信网关采用异步方式实现多通道并行处理发送 2.每个通道配置一个内存队列，一般队列长度为通道速度的4~6倍 3.网关由专门提升发送的线程根据网关下的通道队列判断，如果任务一个队列可用长度大于300时，从DB提取队列对应长度到待发送队列中 4.每个通道配置多个发送线程，不断从待发送队列中取出数据发往运营商。发送完毕后把信息转移到已发送内存队列 5.网关专门有接收响应线程，当异步接收到响应后与已发送队列配对,直接放入待入库内存队列 6.专门单独的线程从待入库队列批量把已发送短信入库 7.网关有专门状态报告线程接收运营商状态报告数据，所有接收状态均先入内存队列。再由独立线程从内存队列批量入库，暂不做处理 8.最后由网关线程组，从状态库报告表取数据批量同步下行表 9.所有数据处理采用内存操作，操作DB部分均采用批量处理

短信发送业务流程（时序图）

短信回复业务流程

开发架构

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

常见问题：

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

运行架构

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

常见问题：

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

物理架构

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

常见问题：

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

微服务架构图

\

\

\

系统采用容器化部署方式，为了做持续的集成和部署，引入了jenkins，利用jenkins来构建应用的docker镜像并push到私有仓库，然后再基于应用的docker镜像来发布项目，这样减少了很多的手动操作，基本能实现持续集成和持续部署。

\

数据架构

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

常见问题：

数据存储在哪？用了什么数据库，如 oracle、mysql；梳理 E-R 图；

数据量有多少？是否有分库分表？用了哪些 nosql 库？

有哪些数据同步任务？大数据框架的使用情况如何？

\

系统运维

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

常见问题：

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

\

实践

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

总结

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