蓝色关注，回复“6”获取技术、产品人必读10本书
见字如面，我是军哥。
今天要分享的不是我，是我的一位架构师读者，以下是他的分享，请各位支持哈！
我是龚钢，从业10多年，一位电商交易业务域的业务系统架构师，今天给大家分享内容的是我对于软件架构能力的一些理解，以及在工作中的一些实践经验。
1、软件生命周期里架构师的职责是什么？
广义上的“架构”其实是一种能力，可以体现在很多地方，并不局限于软件行业。比如我们想要做一件事情，先明确目标，再进行拆解，想好每一步怎么做，然后逐步实现，最后完成既定目标。再比如我们想要建造某一个建筑，首先要想好造什么，有什么功能或者达到什么目的；再进行设计，输出符合功能要求并能够指导施工的各种图纸；然后进行任务分解，监督建造过程，最后进行验收。
这种能力放到软件研发的上下文里就是软件架构，可以贯彻整个软件系统的生命周期。而软件架构师又有很多分类，今天聊的是业务系统架构师的架构能力。下面就来具体分析下，在软件系统生命周期中每个阶段对应的能力及最佳实践。
1.需求阶段。
理解业务目标，串联业务流程，需要具备业务理解能力且能与产品、运营、客户等干系人的沟通的能力。
首先，你需要获取第一手需求，比如参加业务需求沟通会，尽量接触需求的原始提出方，从整体上了解业务背景和目标。然后根据自己所属的业务域或系统，定位职责和边界（需要对所负责系统非常熟悉，系统具备哪些功能、处理能力、接口服务和数据服务等），参与业务流程梳理。最后确定一种在系统实现上预见可行的业务方案。
2.设计阶段。
转化成技术解决方案，需要具备抽象思维和建模能力，从各个架构视角分析和设计系统；技术的深度和广度、权衡和架构决策能力，进行关键技术预研、技术选型和方案决策；风险预估能力，评估潜在的风险，制定解决或规避方案；文档写作和表达能力，把设计思路和实现方案传递给系统相关人。
通常需要输出一份可以指导开发的架构设计文档。
首先，你通过业务流程图，画出系统上下文图，再把相关的系统串联起来，确定系统间的交互方式，画出系统系统流程图（或UML时序图），并设计出接口和DTO对象。
然后进行系统内部设计，可以运用分层、分割、分布式、异步化等手段，将系统拆分成各个功能组件，可以输出用例图、组件图和时序图；
画出每个组件的业务处理流程图，同时需要考虑是否使用缓存、事务和异常的处理，数据一致性的保证（跨系统调用、跨多个分库、缓存与数据库等场景）；
对于一些特定问题（比如如何迁移历史数据、如何生成全局唯一id、如何进行最优价格计算、数据传输和存储如何保证安全等），需要输出多个方案进行对比验证，最后决策出一个最优方案；
对于开发语言（JAVA、C++、C#）、缓存（Redis、MemCached、Caffeine、本地Map）、消息中间件（MQ、Kafka）、数据库（MySQL、MongoDB、ES、TiDB）、系统框架（Dubbo、SpringCloud、自研基于Netty等开源框架）、分布式事务（XA、TCC、SAGA）、运行环境（Docker+K8S/虚拟机/物理机，Tomcat/JBoss，四层/七层负载均衡）等进行技术选型，可以参考其他系统的架构或公司的规范要求；
使用PD等工具进行数据模型和表结构的设计，输出E-R图，并导出生成数据库脚本代码；
最后，你还要考虑一些非功能性需求，比如系统能力评估（能够支撑多少TPS），缓存的内存容量（根据key和value的长度、最多存多少条，多长时间失效进行评估），数据库磁盘容量（根据字段长度计算表的宽度，再根据数据量、分表数量、索引长度估算，还要考虑日志、备份文件的存储，存放多久的数据，历史数据如何归档和查询），可用性（应用、缓存、数据库如何冗余部署，故障如何监控和恢复，如何进行限流、熔断和业务降级），以及如何验证架构和风险评估等等。
3.开发阶段。
开发框架和核心逻辑代码，确保按照设计方案和开发规范逐步达到业务目标，需要具备编码能力、重构优化能力、执行力和跟开发团队的沟通能力。
运用设计模式搭建代码框架，定义好接口和DTO、实体Bean对象。根据实际情况，可以开发实现部分核心功能。评审开发人员输出的详细设计文档，review其他开发人员的代码。参加开发团队的每日晨会，了解开发进度和存在的问题，解决开发过程中出现的各种问题。
4.测试阶段。
主导性能测试，需要具备性能分析和调优能力；参与测试用例评审，确保覆盖所有业务场景，需要具备跟测试团队的沟通能力。
对于核心接口根据压测环境（机器配置和数量）评估压测指标（TPS、RT），提出压测申请。条件允许还可以进行线性压测（用单台、2台、和4台app服务分别压测），可以用于评估系统容量时的参考。
在性能测试过程中，需要根据机器资源（CPU、内存、磁盘IO等）消耗情况，分析是否存在性能瓶颈。JVM参数、GC策略、app服务器连接数、数据源连接数、数据库连接数、索引等是否是最优配置。另外出现以下情况还需要分析 JVM 相关日志文件和代码，如 CPU 消耗曲线是否掉坑、集群内各服务器的 CPU 消耗是否大致相同、YGC或 FullGC 过于频繁等。
测试用例的评审过程中，需要重点关注一些较为复杂的业务逻辑场景和交叉场景（操作会导致相互影响的场景）。另外还需要解答测试人员提出的业务场景问题，配合他们完成测试用例。
5.上线阶段。
主导环境搭建，参与上线方案评审，需要熟悉服务器参数配置，具备跟实施或运维团队的沟通能力。
根据压测报告评估系统容量，以及需要的应用服务器、缓存服务器、数据库服务器等的数量和配置，申请资源并跟进环境搭建，接入发布平台、日志平台、数据采集和监控平台等。
6.运维阶段。
保证系统稳定，主导定位解决线上环境问题，需要熟悉监控工具，具备分析和解决问题的能力，同时也需要具备跟实施或运维团队的沟通能力。
定期通过监控平台检查系统，分析告警日志，发现潜在问题。比如，发现接口的RT，TP99或者异常率增加，可以从以下方面分析：
接口调用量是否有增加，各个服务器 CPU 等资源使用是否有增加，是否触发了 GC、限流；调用方是否未开通访问权限，日志是否存在报错信息；是否集中在某一台服务器，网络抖动或机器宕机；查看接口报文，是否是特定的数据导致数据库慢 SQL，缓存的慢查询。有些可以自己登陆相关平台进行查看，有些需要找相应的运维人员从线上环境取日志文件进行分析，有时候还需要跟基础组件的研发团队讨论分析。
对于可预见的大促或业务流量峰值，还需要提前进行相关准备。比如根据业务量（PV、UV）参考历史数据和压测数据，评估系统是否需要增加机器、缓存的内存、数据库的磁盘；系统健康检查（根据 DBA 提供的数据库检查报告进行优化，数据是否需要归档，分析缓存的慢查询，缓存的内存是否充足，应用服务器 JVM 和 GC 是否需要优化，日志是否自动归档，磁盘是否充足）；检查限流和熔断配置，业务降级方案（哪些接口可以暂时关闭访问权限、哪些定时任务可以暂停，哪些依赖外部系统的接口可以直接返回默认值等）。
具备以上这些能力并承担相应工作职责的人，称为业务系统架构师。然而会这些还远远不够，请继续看下文......
2、其它三项必备能力
此外作为软件系统架构师还应该具备以下能力：
1.业务前瞻性。
理解商业模式和行业知识，对软件产品未来的发展有一定的规划能力。
这部分的能力培养可以通过学习运营、增长、产品、思维模型、商业模式等相关的知识，参加行业峰会，调研竞品等方式，从而能够从技术角度影响产品的发展方向。
2.技术敏感度。
关注不断出现的新技术，理解实现原理，以降本增效为目的，结合实际情况进行引入，可以关注一些高质量的公众号、技术网站、app或者相关书籍进行学习。在面对一些新问题的时候，可以有思路和方向。比如之前用的MongoDB，想使用数据库事务，就可以选择升级数据库版本，或者引入TiDB；想将业务逻辑和服务治理解耦，可以考虑使用istio等服务网格技术。
3.个人影响力。
善于进行总结和分享，具备技术权威性和决策的话语权。
比如经常帮别人解决问题，或者总能解决一些棘手的问题；经常在团队内部进行技术分享，或者在行业峰会上进行分享，发表技术软文，申请技术专利等，都可以提升个人影响力，从而使得输出的技术方案更有说服力，对于系统提出的优化方案也更容易推进，大家也愿意投入资源配合架构师做事情。
以上就是我今天分享的主要内容。软件系统架构师的成长之路充满了未知和挑战，只有在不断地发现问题和解决问题过程中积累和沉淀，逐渐提高架构能力。让我们一起努力吧。谢谢大家！
写在最后
以上，是今天讨论主题的全部。
今天这篇关于架构的文章，我认为非常接地气，欢迎留言交流，如果你想认识作者，也欢迎加我微信，我把你拉到我的高质量读者群里，互相交流讨论哈！
关于我：军哥，前饿了么、贝壳技术总监，乐于结交朋友，也欢迎加我微信与我做朋友（公号输入框回复“w”即可），朋友圈做个点头之交！
以往热文推荐：
更多精彩，关注我公众号，一起学习、成长
▲ 长按关注军哥手记，一起学习、成长
873
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
