前言在40岁老架构师 尼恩的读者交流群(50+)中,很多小伙伴问尼恩:
诸如此类,问法很多,但是不知道架构图长成啥样?架构方案怎么写。 40岁老架构师尼恩,不知道做过多少架构方案。也不知道指导了多少开发,完成了架构师的华丽转身。 现在,给大家提供一份如何画好架构图,和如何做好架构方案,核心的要点,展示给大家。 使得大家可以充分展示一下大家雄厚的 “技术肌肉”,让你的主管、同事爱到 “不能自已、口水直流”。 也一并把这个题目以及参考答案,收入咱们的 《尼恩Java面试宝典》V53版本,供后面的小伙伴参考,提升大家的 3高 架构、设计、开发水平。
系统架构图是为了抽象的表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界,以及软件系统的物理部署和软件系统的演进方向的整体视图。好的架构图可以让干系人理解、遵循架构决策,就需要把架构信息传递出去。那么,画架构图是为了:解决沟通障碍/达成共识/减少歧义。比较流行的是4+1视图和C4视图。 一:怎么画好架构图一个好的架构图是不需要解释的,它应该是自描述的,并且要具备一致性和足够的准确性,前瞻性,能够与 后面的设计相呼应。 架构方案的受众分析架构方案,也要 千人千面 在画出一个好的架构图之前, 首先应该要明确其受众,再想清楚要给他们传递什么信息 , 一个方案,面向不同的受众,需要有不同的视图 不是为了画图而画图,而是应该差异化分析 要进行受众分析,应该根据受众的不同,传递的信息的不同,用图准确地表达出来,最后的图可能就是在这样一些分类里。 视图的分析维度针对不同的受众,有不同的分析图 但是,也是层层深入的 大概有下面的 8个维度 架构图1:场景视图用于描述系统的参与者与功能用例间的关系, 反映系统的最终需求和交互设计,通常由用例图表示; 场景分析图的受众: 外部的技术或非技术人员,包括团队内部或外部的开发人员或运维人员, 架构图2:系统架构分析系统架构分析 用于描述系统软件功能拆解后的组件关系,组件约束和边界,反映系统整体组成与系统如何构建的过程,通常 子系统的 线框图表示。 架构图3:系统依赖分析(System Context Diagram)系统依赖分析(System Context Diagram)用于描述要我们要构建的系统是什么,子系统直接的依赖关系是什么,用户是谁,需要如何融入已有的IT环境。 系统依赖分析图的受众: 外部的技术或非技术人员,包括团队内部或外部的开发人员或运维人员, 架构图4:子系统依赖分析(Container Diagram)子系统依赖 是 系统依赖图里 ,对待建设的子系统做了一个内部依赖关系展开分析, 子系统依赖分析 主要用来描述子软件系统的内部的依赖关系,分析系统中的职责是如何分布的,子系统是如何交互的。 子系统依赖分析的受众: 外部的技术或非技术人员,包括团队内部或外部的开发人员或运维人员, 架构图5:组件架构图(Component Diagram)组件架构图是把针对某个子系统 进行组件设计、模块设计, 组件架构图 用于 子系统 的模块关系,介绍 子系统由哪些组件/服务组成,了组件之间的关系和依赖,为软件开发如何分解交付提供了框架。 组件架构图受众:主要是给内部开发人员看的。 组件架构图的作用:为代码的组织和模块架构,提供支撑 架构图6:模块架构图从编码的维度来说,组件内部,很多模块。模块架构分析 ,是对组件的进一步 深入分析。 模块架构分析用于描述模块划分和组成, 模块架构分析可以细化到内部包的组成设计,服务于开发人员,反映系统开发实施过程。 架构图7:逻辑架构视图逻辑架构视图 用于描述系统模块内部的的通信时序,数据的输入输出,反映系统的功能流程与数据流程,、 通常由时序图和流程图表示。 架构图8:部署架构分析用于描述系统软件到物理硬件的映射关系,反映出系统的组件是如何部署到一组可计算机器节点上,用于指导软件系统的部署实施过程。 二: 怎么做好架构方案?光有图是不够的,还要有方案 下面是一份P8 级专家的架构方案 提纲如下:
2.1、现状现状,主要是用来描述当前这个业务(项目)的一些基本情况介绍和相关的背景。 方案设计出来之后,是需要给你的 leader 或者团队其他成员进行评审或者查看, 一般来说,由技术委员会来评审 但是别人不可能都和你一样清楚你的项目, 因此首先,你要把你项目的基本情况和背景都说清楚,让大家达成一个共识, 大家站在同一个起点上,才能进行后面的方案评审和讨论。 业务背景业务背景就是你这个业务的基本介绍,包括但不限于:
技术背景技术背景就是项目是基于什么样的技术背景下来构建的, 可以是从 0 到 1 来构建,也能是基于现有的方案来优化, 但是不管是什么场景,一定都会存在相关的技术背景,因此包括但不限于:
2.2、需求需求,很重要! 不管你的技术有多牛逼,都一定为需求服务的, 不管这个需求是技术需求,还是业务需求,一定都是要为需求服务。 注意:需求,这个需求可以是当下的需求,尽可能 包含未来潜在的需求。 需求越完善,后面会少走弯路。 业务需求业务需求就是你这个业务具体要做的事情,包括但不限于:
业务痛点
性能需求除了业务需求,还要从这个业务需求里面考虑清楚我们满足这个业务之下的性能需求点, 如果一个系统不考虑性能,可能流量一上来,服务就挂掉了。 性能需求包括但不限于:
2.3、方案描述前面把现状和需求说清楚后,终于到了我们的重头戏,方案描述这里了。 一般,需要会有几个可选的方案, 也就是说,尽可能把相关可能的方案都描述清楚, 然后给出你认为的最合适的方案,然后让大家来评审和决策,看是否同意你的意见或者有其他更好的意见。 除非万不得已,最好,不要一只有个方案。 方案1概述说明一下方案的核心亮点、核心特色,核心目标,核心优势 比如说:高性能、可扩展、双写、主从分离、分库分表、扩容等。 详细说明详细说明这里需要图文结合, 包括但不限于架构图、流程图 等。 把你整个方案的架构和模块、细节流程都描述清楚 性能目标性能一般来说可能包含以下部分:
资源评估给出方案的基准数据,并按性能需求评估需要使用的资源数量。 按照预估性能需求,预估资源数量
方案优缺点列出方案的优缺点, 这个需要通过量化的指标来支撑 方案2可选的另外一种方案,模板和上面一样。 方案对比前面给出了多种可选的方案,那么这里就是进行一个简单的对比, 然后,给出自己的觉得最优的方案,并且给出支撑的数据、理由。 有了你自己的决策(倾向)的方案后, 当然,对于最优的方案,就应该提供更有支撑力的细化的方案和数据 2.4、线上方案线上方案是对上面你更倾向的方案的更为细致的描述。 架构图整体架构是如何,把架构图画上 关键设计点 和 设计折衷把核心的关键点,用自己的 名词系统表达出来 这里有一个要求:整体是完备的、自洽的 用来确保你的方案的大体方向是 OK 的。 因为没有一个方案设计是最完美,方案设计都是逐步演进和优化的, 但是,一定是完整的、系统的、没有大漏洞的 还有,方案设计是要最符合当前的背景的。 业务流程对于业务的核心场景,弄一个整体流程图、核心流程图出来, 然后分业务场景把各个业务场景的流程图也画出来,并且做好相关介绍 模块划分模块的划分需要考虑我们架构设计的一些原则, 比如:架构分层、业务分模块、微服务化、高内聚低耦合 等。 然后把每个模块的功能点都说清楚 异常边界【重要】异常边界是比较重要的,一般情况下, 大部分人都能考虑到正常的处理流程,对于异常的边界考虑的比较少, 但是线上出问题,大部分都是异常情况导致,因此这里非常重要!!! 我们可以通过一个 思维导图 去整理相关的异常边界, 这样有助于自己在实现的时候有足够的把控度,也便于别人去 review 你的方案和具体实现(如 coding) 异常边界需要考虑:
监控、预警、统计线上运行的项目,一定需要有各种监控,预警、指标统计 可以使用 公司内部的基建的监控外, 还需要从业务内部,实现自定义的一些业务监控和相关技术统计 最终的目标、保证系统的高可用、支撑系统的高可用 灰度、回滚策略
容灾方案容灾就是当出现 IDC 异常的情况下,怎么容灾,这个可以根据实际情况去考虑。 2.5、部署架构可以按照下面的方向,去做拓展:
2.6、风险评估标识所选方案的风险,提出解决此风险发生时候的应对策略, 比如:上线失败时的回滚策略。 潜在风险
2.7、阶段规划【架构演进规划】架构怎么演进 阶段如何规划 每个阶段该达成什么目标 第一阶段 目标 XXXX 第二阶段 目标 XXXX 第三阶段 目标 XXXX 2.8、投入评估最后,需要做投入的评估,作为投资回报分析的支撑,包括:
这里需要细化到每个模块、 工作量评估 一般按照时间进行,一定要同时包括开发时间、联调时间、测试时间。 最好比较细化,不要太粗, 比如开发时间可以细化到接口的维度,每个接口的设计分别需要多长时间, 老马识途,找老架构取经只要是成功走上架构师岗位的都指导, 架构之路,充满了坎坷 这个和高级开发不一样 , 架构的问题,是open的,开发式的,没有答案的 在架构设计的过程中, 会遇到无数的挫折,很多小伙伴, 就没有跨过去 其实,如果真的遇到架构难题,找有经验的人帮帮忙, 这道坎,就过去了 所以,如果遇到复杂的场景,确实不知道怎么做架构方案,怎么办? 可以来尼恩的技术自由圈(疯狂创客圈圈) 中求助. 咱们圈聚焦架构研究,这里有上1000位架构人脉,10年多架构经验的老架构师,在100位以上。 大家 什么架构方案都做过,可以给遇到困难的小伙伴,提供设计帮助、架构帮助。
|
|
来自: 昵称34195792 > 《待分类》