该怎么向别人介绍你们的系统架构?

如果有人让你介绍你们做的系统架构是什么样子的 你会从哪说起?


每个人都会有自己的架构认知,根据自己的接触的内容来总结。系统分为用户中心、营销中心、商品中心…… 这是产品经理说的;我们的系统用了三层架构,用了SSM框架…… 这是程序员说的;用户说 我们系统有后台,前台,商品上下架功能,用户管理功能。


在实际工作中架构师架构出来的系统不仅要考虑用户的功能实现,而且也要平衡系统的易用性、高性能、扩展性、可伸缩性等方面,这里面是要综合业务目标、当前开发人数、开发人员的综合能力、上线时间、项目预算等来选择开发语言、开发框架和功能开发的顺序。有些公司求时间、有些公司求质量,但最终说明架构是实时变化的,不是一上来就来个完美的架构,是要根据当前的业务需求变化的,但你的架构必须要支持这种变化 达到上面所说的要求。


一个复杂的系统需要不同角色的人来参与,因此架构师必须考虑到让不同的参与者理解你的架构 知道他们自己该做什么事,如用户为你提供原始需求,项目经理需要制定计划 在不同小组间沟通 落地你的架构,开发人员拿到你的设计实现功能。所以架构涵盖的内容和决策太多了,需要从不同视角分别设计 ,也是为了架构方便理解、交流和归档的方便。


最常用的架构分为:逻辑架构和物理架构视图


逻辑架构


逻辑架构规定了由哪些逻辑元素组成以及这些逻辑元素间的关系,逻辑元素可以是逻辑层、功能子系统、模块。

640?wx_fmt=png&wxfrom=5&wx_lazy=1

物理架构


展示模块间的部署逻辑,数据如何产生、哪块计算、怎么存储、共享等在计算机中的情况。

 640?wx_fmt=png

这里暂时先列出概念,架构设计之初避免涉及太多具体的技术细节,需要看透需求,寻找出实现的难点、以质量还是时间优先。


5视图法:逻辑架构、物理架构、数据架构、开发架构、运行架构


640?wx_fmt=png


面对不同的角色需要用不同的思维来表达,对领导汇报用业务图而不能讲技术架构,对开发则可讲具体开发架构,对运维讲运行架构、物理架构,因此需要不同的架构设计来表达。


逻辑架构


逻辑架构= 模块划分+接口定义(统一接口规范)+领域模型


物理架构


物理架构=硬件分布+软件部署+方案优化(可伸缩性、高性能、易维护性,监控)


物理架构,更关注的系统、网络、服务器等基础设施。例如:如何通过服务器部署和配置网络环境,来实现应用程序的“可伸缩性、高可用性”。或者举一个实际的例子,如何通过设计基础设施的架构,来保障网站能支持同时10W人在线、7*24小时提供服务,当超过10W人或者低于10W人在线时,可以很方便的调整部署架构来支撑。


数据架构


数据架构=存储方式+数据分布


数据架构,更关注的是数据持久化和存储层面的问题,也可能会包括数据的分布、复制、同步等问题。更贴切来讲,如何选择需要的关系型数据库、流行的NOSQL,如何保障数据存储层面的性能、高可用性、灾备等等。很多时候,和物理架构是有紧密联系的,但它更关注数据存储层面的,物理架构更关注整个基础设施部署层面。


开发架构


开发架构=技术选型+文件划分+编译关系(模块依赖关系)


开发架构则更关注程序包,不仅仅是我们自己写的程序,还包括应用程序依赖的SDK、第三方类库、中间价等。尤其是像目前主流的Java、.NET等依靠虚拟机的语言和平台,以及主流的基于数据库的应用,都会比较关注。和逻辑架构有紧密的关联。


运行架构


运行架构=物理架构+数据流的控制(系统运行中的数据流向关系)


顾名思义,更关注的是应用程序运行中可能出现的一些问题。例如并发带来的问题,比较常见的“线程同步”问题、死锁问题、对象创建和销毁(生命周期管理)问题等等。开发架构,更关注的是飞机起飞之前的一些准备工作,在静止状态下就能规划好做好的,而运行架构,更多考虑的是飞机起飞之后可能发生的一些问题。


实现架构设计的6个步骤


需求分析


根据系统使用人、客户等收集而来的业务实现的背景要求组成的原始需求文档分析,包括了功能要求、质量(性能要求)、约束(时间、预算、可行性分析、风险评估、是否需要对接三方)。这里要输出一份整理过后的需求文档,包含了要做什么(功能范围、非功能性需求),能不能做,能做到的前提要求和要面临的问题,怎么做(进入系统分析实现阶段)。


确定关键需求


不仅要对功能需求(如用例)进行筛选,还要对非功能需求进行权衡,最终确定对架构起关键作用的需求。如需求是以高性能并发度为关键还是以可扩展性为要求或同时满足,因为考虑到成本、上线时间和现有系统的影响会舍弃一部分需求,需要确定关键需求:核心功能、高风险功能。


概念架构设计


1个决定4个选型:决定如何划分顶级子系统;架构风格选型(C/S还是B/S架构);开发技术选型(java);集成技术选型(API);二次开发技术选型(API)。


细化架构设计


5视图法:分别从逻辑架构、物理架构、数据架构、开发架构、运行架构进行设计,每一块的关注点不一样,可细化粗粒度。


领域建模


领域建模的精髓是 业务决定功能,功能决定模型。将需求业务转化为抽象的模型对象之间的流转关系。


常用的表达方式是类图 表达模型之间的关系,听得最多的是“建模”。模型的建立也是逐步完善的,还包含了状态(流程图)、特性要求等文字说明。


关于如何领域建模 有专门的 领域驱动设计 方面的书可以参考。


架构验证


可快速开发一个统一框架(一个原型、一个技术难点)来贯彻架构的设计,再对原型进行测试评审 再对架构进行补充。 


最后可以总结为可以用5视图法从各方面来描述系统的架构,然后用6步骤来描述怎么实现架构。不过现在还流行一种就是将业务逻辑与物理架构放一起 忽略其中的实现细节。 


软件架构就是实用而且优雅的设计,它不在于分多少层,或者应用了多少种设计模式/架构模式等。它应该是以满足实现用户需求为前提,以开发人员普遍可接受为根本的,而且要符合系统特性和业务发展需要的,从软件设计的角度,能够达到层次清晰、可维护、可重用、可扩展…就非常优秀了,无需刻意去纠结分了多少层,是否使用了什么模式,有多么抽象等。以面向对象设计为例,基本目标是“高内聚、低耦合”,为此我们可能会遵循一些常见的设计原则(例如经典的SOLID设计原则)。


通常我们所说的模式,其实又分为很多种,并不是仅仅指的是“设计模式”(设计模式也有千千万,并不是只有常见的GOF 23种设计模式)。通常包括:企业架构模式、设计模式、SOA模式、企业集成模式等等。


强调一下,架构要讲求“实用”,而且开发人员普遍可接受,要符合现状的。否则,再“优雅”的设计,都会沦为高成本的“花架子”,生搬硬套和过度设计只会让项目“流产”。


出处:http://www.cnblogs.com/zhangs1986/p/8707721.html


版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢。


640?wx_fmt=png

架构文摘

ID:ArchDigest

互联网应用架构丨架构技术丨大型网站丨大数据丨机器学习

640?wx_fmt=jpeg

更多精彩文章,请点击下方:阅读原文

阅读更多
上一篇中国邮政大数据平台建设之总体架构与实现
下一篇平均年薪35W,2018年大数据AI发展趋势分析
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭