软件架构设计指引.docx

《软件架构设计指引.docx》由会员分享，可在线阅读，更多相关《软件架构设计指引.docx（10页珍藏版）》请在优知文库上搜索。

1、软件架构设计指引良好的软件架构的可以帮助我们：让整个团队跟随一个清晰的技术愿景和技术路线图。对不同层次的干系人提供关于系统的完整、清晰、一致的视图。技术领导力和更好的协调统一的技术术语和模型，更方便团队的交流，减少彼此的误解。识别和控制风险结构良好的代码，为应对变化建立坚实的基础。1、如何做到“恰如其分?关于架构设计，一个最主要的争论是要做到什么地步的预先设计才是刚刚好？传统的瀑布模式强调事无巨细的架构设计与详细设计，甚至写出所有的伪代码。而敏捷方法推崇浮现式设计。其实，敏捷方法从未说过不做架构设计，也没有宣布过不写文档。对于开发之前的预先架构设计，我们认为需要根据项目的实际情况进行取舍，做好

2、能够很好的支持开发工作，控制风险就是刚刚好，具体的一些经验如下：多少预先设计是太少了？如果有以下的任何情况，说明预先的架构设计做的不够，如果贸然启动开发会带来巨大风险：.不了解系统的边界是什么，在哪里？.团队成员对系统的“BigPiCtUre”没有形成共识无法交流整体愿景 团队成员对需要做的事情不清楚或感到茫然，不知道该如何开始编码 没有考虑非功能需求或质量属性没有考虑环境约束如何影响软件（部署环境等）.没有考虑过技术风险.尚未确认重大问题的对策 没有考虑关注点分离，适当的分层、可修改性，可测试性等.团队成员使用的技术选型不一致 团队成员对于解决方案是否管用没信心多少预先设计太多了？.很多信息

3、，太多太细的文档 在文档中编写太多的伪代码 太多图表过于死板，开发人员感觉缺少灵活性，编码变成翻译工作序列图，非常多的乏味的序列图.太长的设计时间，还没开发项目截止时间已经快到T2、架构设计原则软件产品的技术架构应参考以下原则进行设计，对于无法满足的情况需要在架构评审时进行明确说明。原则说明1 结构清系统纵向的分层和横向的分模块结构清晰晰合理，层次分明，概念清晰一致2 SOLID通过有效运用以下六个原则实现逻辑结构和程序结构的清晰灵活，能够应对变化： 单一职责原则(SingleResponsibilityPrinciple-SRP) 开放封闭原则(C)PenClOSedPrinciple-0C

4、P) 里氏替换原则(LiskovSubstitutionPrinciple-LSP) 最少知识原则(LeastKnowledgePrinciple-LKP) 接口隔离原则(InterfaCeSegregationPrinciple-ISP) 依赖倒置原则(DePendenCeInversionPrinciple-DIP)3 N+l设关键组件永远不少于两个冗余，通常三计个。不引入任何单点故障风险4 无状态只有当业务确实需要的、没有任何其他方设计案替代时才使用状态5 配置外发布包中不能包含任何环境相关的配置置信息，应通过环境变量等方式注入6 功能开能够不停机打开或关闭任何发布的功能关7 故障隔实现

5、故障隔离设计，通过断路保护避免故离障传播和交叉影响8 异步只有在绝对必要的时候才进行同步调用9 监控设在设计阶段就必须要充分考虑如何监控,计无监控不上线；10日志流仔细设计日志的输出，把日志当作事件流输出和使用11弹性伸支持弹性伸缩，启动迅速、优雅终止、面缩对突然伸缩时保持健壮。12水平可扩展方法要选择水平扩展非垂直升级：永扩展远不要依赖更大，更快的基础设施13自动化对开发、测试和生产环境都进行了完整的规划设计，尽一切可能实现各个环境实现发布和变更自动化。14不锁定使用商品化的通用标准硬件，尽量不绑定到特殊的硬件厂商或硬件产品15慢半拍只用已经证明确实好用的，成熟的技术16成本最如果是不擅长的

6、、非核心的、不会带来竞优争优势的组件的则考虑直接购买选用成熟产品3、设计方法整体架构设计方法遵循C4架构设计方法。C4指的是：系统的架构=上下文(Context)类(ClaSS)组件(Component)+容器(Container).Context 总体蓝图设计、系统的职责、环境上下文，外部关系.Class 领域模型设计：说明系统的核心务逻辑、核心概念类、模块划分设计.Component 系统的逻辑实现设计，包括重要组件、数据结构、程序结构Container系统物理实现设计，部署结构以及技术选型基本的架构设计流程可分为如下六个步骤：1）、深入理解需求，即需要设计一个什么样的系统，该系统在生产环

7、境与其他系统和外部实体是如何交互的？功能需求和非功能需求到底是什么？架构师应主动参与到需求分析和需求评审的过程。2）、概念设计（ConteXt,Class）,对业务进行分析，梳理出系统的业务领域（模块、子系统）、重要的概念（对象、数据实体）、以及概念之间的关系。并形成领域模型，具体可参考领域驱动设计；3）、逻辑设计（CIaSS,Component）,根据概念设计的领域模型，设计出系统的逻辑模型（组件或服务、以及组件内部的程序包、对象、数据库结构等逻辑对象），并按照组件概要说明基本结构。包括类设计如涉及数据库，要进行物理数据模型设计，推荐使用PoWerDeSigner进行设计。接口设计 技术分层

8、设计：进行分层次的技术架构设计，例如展示层、业务逻辑层、DAe）层等。4)、11PWiSi+(Component,Container),包中舌 部署设计，设计组件如何部署到运行环境。将运行环境抽象为一个个容器（节点），说明逻辑组件或服务如何部署到容器中，以及容器之间的通讯关系。 环境设计，详细设计系统所使用的sit,uat,prod等环境，以及对应的自动化部署方案； 安全架构设计，详细设计系统的信息安全架构； 非功能需求的方案设计：针对可靠性、安全性、高可用性、以及运维监控需求等进行方案论证与设计。5）、技术选型 技术选型，根据系统的逻辑设计和部署设计选择合适的操作系统、数据库、第三方软件、S

9、DK,开源程序包等；6）、架构评审 进行技术架构评审，基本过程参见本文第5章节。4、设计流程在一个敏捷的团队里，人人都是架构师，软件架构设计应该由研发团队整体负责，同时为了协调架构设计相关的事情，会由SDM或一名资深的SDE主导架构设计,主导者需要承担如下职责：.深入理解需求和业务目标，架构师应该在深入理解业务需求和目标，并且能够更抽象一个层次，把握会导致需求变动的各种因素。 设计软件.控制技术风险 管理架构演化，软件的架构是动态的，会不断演化。 与其他成员一起编写代码（注意软件研发团队中没有不写代码的架构师） 保证质量在一个研发项目过程中，基本的架构设计流程如下：阶段设计工作说明、/.技术可行性协作产品经理完成产品的技术可项研究行性研究启初步设计完成初步的架构技术选型以及关动键技术的研究，控制技术风险主要交付物为2.2.模板-初步设计方案.PPtx定架构设计完成系统的整体性架构设计，并完义成架构评审主要交付物为2.3-模板系统架构设计说明书模板docx实详细设计以根据架构设计完成详细设计，并在施及架构设计的变更迭代过程中对架构设计进行补充和优化必要时可以修改架构设计主要交付物为2.4-模板-系统部署方案模板.dOcx2.4-模板-系统接口规格说明书模板.docx验设计交付文完成架构设计相关文档的验收归收档的归档档