系统架构设计应该如何做

​系统架构应该如何设计，从自己做架构的经历来分享一些体会。根据每个人的思维习惯不同，我的这些思考不见的都适合你，但多少对大家会有所帮助。

1、如何进行架构设计

系统架构的设计需要遵循一定的步骤和原则，这里我从：架构需求、架构顺序、架构文档、架构复审、架构实现和架构演化5个方面谈一些自己的理解。

• 体系架构需求

全面获取和分析用户对软件系统功能、性能、界面、设计约束等方面的期望，也就是需要了解用户的真实需求，并将每一个需求项目抽象定义为构件（类的集合）。

• 体系架构设计

通常会采用迭代的方法。

首先选择一个合适的软件体系架构风格，如C/S、B/S、N层、管道过滤器风格、C2风格等，作为架构模型，然后将需求阶段标识的构件映射到模型中，分析构件间的相互作用关系，最后形成量身订做的软件体系架构。

• 体系架构文档化

生成用户和研发人员能够阅读的体系架构规格说明书和体系架构设计说明书。

• 体系架构复审

及早发现体系架构设计中存在的缺陷和错误，及时予以标记和排除。

• 体系架构实现

设计人员开发出系统构件，按照体系架构设计规格说明书进行构件的关联、合成、组装和测试。

• 体系架构演化

如果用户需求发生了变化，则需相应地修改完善优化、调整软件体系结构，以适应新的变化了的软件需求。

2、架构设计注意事项

在进行架构设计时，以下是一些需要注意的事项。

• 分治原则

将系统划分为多个子系统或模块，每个子系统或模块都可以独立地进行开发、测试、部署和维护。这样可以降低系统的复杂度，提高系统的可维护性和可扩展性。

• 服务自治

每个服务都应该具备独立的能力，能够独立地进行开发、测试、部署和维护。这样可以提高服务的可用性和可靠性，降低系统的耦合度。

• 拥抱变化

系统架构设计应该能够适应业务需求的变化和市场的变化，具备快速响应和灵活应变的能力。

• 可维护性

关注系统运行日志和调试模块，便于开发和维护时的诊断和调试。关键事件和主要处理流程添加必要日志，同时注意日志信息与日志级别合理设置，使关键事件与运行信息有log可追踪。集公共特性为机制，集公共机制于平台。

• 考虑依赖和限制

熟悉业务逻辑，并考虑相关模块的能力和限制；比如基础模块的数据转发或处理性能限制，会不会导致消息丢失或block；重构或改写代码前，一定要先把原先的业务和代码吃透，了解为什么需要重构，原来代码架构遇到了什么瓶颈或问题，重构的目标是什么，能cover设计的所有问题吗；因此慎用重构，不要过早的优化，可以小规模改图或优化。

• 适合原则

在进行系统架构设计时，首要遵从“适合原则”。

架构师首先是技术管理者，技术方案选型权衡取舍做技术决策是核心的职责，那么系统架构设计首先要考虑的就是要满足当前业务出发同时能支持适应业务发展而扩展开发维护，同时也要结合团队技术积累和实力、项目时间和成本投入等全方位的综合评估取舍，而不是为技术而技术。

最后，系统架构设计需要遵循一定的步骤和原则，同时要理解业务需求和团队的技术实力，做出合理的架构决策。

• 阅读代码注意事项

首先从用户角度整体认识产品；了解业务使用场景，核心功能以及周边交互模块，缩小问题范围；并体验一下，有个整体的感性认识。