架构设计_架构设计模式 - CSDN
  • 对软件架构设计的一些总结和理解

    万次阅读 多人点赞 2019-05-06 18:16:01
    1. 软件架构设计的What & Why ● 啥是软件架构(Software Architecture)? 软件架构是指在一定的设计原则基础上,从不同角度对组成系统的各部分进行搭配和安排,形成系统的多个结构而组成架构,它包括该系统...

    1. 软件架构设计的What & Why

    ● 啥是软件架构(Software Architecture)?

    软件架构是指在一定的设计原则基础上,从不同角度对组成系统的各部分进行搭配和安排,形成系统的多个结构而组成架构,它包括该系统的各个组件,组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。

    软件架构设计就是从宏观上说明一套软件系统的组成与特性。

    软件架构设计是一系列有层次的决策 ,比如:功能与展现的决策;技术架构的决策;自主研发还是合作;商业软件还是开源软件 。

     

     

    为啥要进行软件架构设计?

    业务需求层出不穷;软件系统越来越复杂;参与的人越来越多;共性和特殊性的问题越来越多;技术发展日异月新;……

     

    2. 软件架构师

     

    2.1. 软件架构师是干什么的

     

    介于需求与开发的中间人     良好的沟通能力
    能够统领全局的大牛 良好的大局观
    能够将需求转换为技术     洞悉前沿与市场嗅觉
    能够为软件研发提供指导     见多识广的大牛
    需要全面思考软件系统方方面面的问题     缜密地思考问题
    能够攻关和搞定重要技术难题     公司可信赖的支柱

     

    2.2. 架构师的素质

     

    全局思维  

    从业务、市场,到技术实现;

    从软件的过去、现在,到将来;

    从外部客户,到内部研发;

    从软件研发,到硬件部署;

    从功能实现,到运行效率  

    战略思维  

    在所在行业的发展战略;

    在业务领域的发展战略;

    在技术方向的发展战略;

    在潜在市场的发展战略。

    前瞻思维  

    市场趋势的发展动向;

    前沿技术的发展动向;

    竞争对手的发展动向;

    合作伙伴的发展动向。

    抽象思维  

    各项业务需求:抽象成功能模块;

    各项功能的实现:抽象成软件架构。 

    逆向思维

    假如不实现会怎样?

    假如没搞定会怎样?

    假如没有它会怎样?

    假如被延期会怎样?

     

    2.3.  架构师的分类

    随着行业和社会的发展,架构师的定义和分类越来越广泛和细分,广泛和细分其实并不矛盾,如果“广泛”是x轴,“细分”是y轴,则二维坐标系x和y轴中间的任一点就是一种架构师类别。但总体来说,或目前来说,集合业界的大致认知,总结如下:

     

    No. 分类 描述
    1 解决方案架构师 与客户探讨业务需求,将业务、市场,与技术、产品结合起来,为客户提供解决他们需求的方案。
    2 系统架构师 也称应用架构师。最终确认和评估系统需求,并将业务转换为技术,为研发人员制订核心框架与技术规范 为研发工作澄清技术细节并扫清技术障碍 。
    3 平台架构师 这里的平台其实包括两个平台,一个是系统平台,也就是负责搭建多个系统整合的系统应用平台;另外一个其实是基础平台,是专门负责搭建基础技术平台;两者其 实区别蛮大,也经常容易被从业人员混乱。举个简单例子,金蝶有平台架构师一职,但是金蝶BOSS应用和金蝶中间件两者招聘的对象和技术要求是截然不同的。
    4 业务架构师 业务架构其实已经开始脱离技术层面了,但是它要求架构师有跨越多系统的大局观,去整合和组织不同系统的技术平台与交互模式。其实这个职位的未来也就是CIO了。
    5 网络架构师 过去,我们可能听的最多的是网络工程师。不错,一个优秀的网络架构师必须有足够的网络技术基底,并且它的关注点也是系统的基础架构。比如说如果搭建并优化集群环境,如果构建基于云计算的系统应用与部署等等。它对于像淘宝、腾讯这样的互联网公司是极其重要的。
    6 移动架构师 移动互联网的迅猛发展横向和纵向都细分出了很多新的职责和岗位,移动架构师的职责和作用日益重要,既要整体和全局考虑整个前后端的软件系统架构,又要重点深入移动客户端的架构设计的方方面面,既要有跨平台思维,又要拿捏好原生和混合开发的尺度,另外移动应用的特点,导致移动架构师必须要比传统系统架构师更加注重非功能性的质量属性。
    7 前端架构师

    这也是互联网的迅猛发展而细分出来的新的职责和岗位,这里的前端特指Web开发中的前端,主要考虑前端呈现层的设计(HTML/CSS/JS/AJAX/RIA/…),跨浏览器设计,性能优化等等。

    注:这些年,在很多互联网一线大厂,Web前端和移动客户端有融合为大前端的趋势和内在需求,所以,大前端架构师的知识领域和职责范围也有不同的涵盖和侧重。

    8 ... ...

     

    3.  软件需求

    软件架构设计中常说需求驱动架构设计,可见需求在整个架构设计中起到了关键指引和方向的作用,如果以目标导向为原则,则需求的满足和实现就是架构设计的终极目标。
    OK,在进行架构设计之前,我们先看下软件需求。

    3.1.  软件需求怎么来的(软件需求的过程)

     

    阶段

    需求阶段

    说明

    什么人做什么事

    可能产生的文档

    客户方

    实施方

    客户方

    实施方

    1

    业务需求

    高纬度抽象的需求,也是来自客户的原始需求,背景描述,业务诉求和期望目标。

    项目负责人或接口人描述需求或提供客户方需求文档。

    销售或售前接触客户,听取和记录需求。

    工作说明书(SOW),或邀标书

    售前的方案建议书

    2

    用户需求

    通常是在问题定义的基础上进行用户访谈、调查,对用户使用的场景进行整理,从而建立从用户角度的需求。

    项目负责人或接口人接受访谈和调研。

    需求分析师或项目经理等进行需求调研。

     

    调研计划、用户需求调研提问库、调研日志、用户需求说明书

    3

    软件需求

    从系统实现的角度描述的需求。开发人员(设计和分析人员)在业务需求、用户需求的基础上形成的。

     

    需求分析师或项目经理、架构师等讨论和细化需求,编写需求文档

     

    SRS(Software Requirement Specification)软件需求规格说明书

     

    3.2.  软件需求的分类:

     

    另外,也有McCall软件质量模型:

    注:在架构设计中,对非功能性需求的重视程度,也会影响架构设计的好与劣;但也要平衡过渡设计和适可而止的关系。

     

    4.  软件架构的过程

    业界软件架构设计的方法论很多,各有各自的应用场景和特点,下文结合ADMEMS(Architecture Design Method has been Extended to Method System)架构设计方法论说明软件架构的过程:

     

    架构阶段

    目标

    方式方法

    现实工作场景

    预架构阶段

    全面理解需求;需求结构化,摒弃“需求列表”,建立二维需求观(ADMEMS矩阵)。

    使用ADMEMS矩阵方法,捋清需求间关系和发现衍生需求。

    1、与人:与项目经理、需求分析师等内部需求人员了解需求;与客户了解需求(不建议架构师做需求分析师角色)。
    2、与物:了解《需求规格说明书》等需求文档。"
    3、对需求有什么问题,反馈给售前或销售,可能会参与拜访客户或电话会议。
    4、销售或售前有时会要求提供一个大致的工作量,以便他们初步评估项目可行性。

    概念架构

    高层组件及其关系

    1、初步设计,基于关键功能,借助鲁棒图进行以发现职责为目的的初步设计(不是必须)。
    2、高层分割,将复杂系统切分为多个二级系统或多个子系统。
    3、考虑非功能需求,采用ADMEMS推荐的目标-场景-决策表。

    1、参与内部讨论:项目可行性分析、讨论,从需求、技术、人力、风险等角度提供建议。
    2、项目投标准备:参与投标团队的技术方案编写,编写系统架构章节,解决招标书上技术问题的问答。
    3、参与项目讲标:作为讲标团队成员参与项目讲标,负责技术问答环节的应对。

    细化架构

     

    5视图法

    在项目概要设计阶段,进行架构设计,制定规范和约定,为详细设计提供指导。

    实现

    详细设计
    编码实现

    架构设计形成详细设计文档

    在项目实现阶段,对开发人员提供规范指引和技术支持。

     

    注:架构设计的过程和内容的不是固定不变的,现实中,比如售前提供解决方案中,很多时候需要架构师提供细化架构中才会深思的逻辑架构、物理架构等,这时候,架构师就需要有螺旋思维和跳跃思维的方式,就像武功中,招式是死的,人是活的,要学会灵活运用。

     

     

    5.  软件架构设计的方式方法

     

    5.1.  多视图法


    多视图方法是业界广泛认同的一种架构设计思路,包括:
    ● SEI的3视图法:
    模块视图、组件-连接器视图、分配视图。
    ● 西门子的4视图法:
    概念视图、模块视图、代码视图、执行视图。
    ● RUP的4+1视图法:
    用例视图、逻辑视图、开发视图、进程视图、物理视图。
    ● 联邦企业架构框架:
    技术架构视图、信息架构视图、应用架构视图、业务架构视图。
    ● ……

    5.2.  5视图法

    5视图法分析的意义:

    ● 全面分析软件系统方方面面的问题
    ● 尽早地发现和排除项目风险与不确定因素
    ● 从不同角度去展现要设计的软件系统
    ● 为项目进行中不同的干系人提供指导:
        -- 逻辑架构描述系统功能,并指导系统测试
        -- 开发架构规范软件的层次及代码风格
        -- 数据架构指导数据库的设计
        -- 运行架构定义了一些关键过程的设计
        -- 物理架构明确软件如何部署与实施

    5.3.  5视图法设计步骤

    两种观念:

     

    观念

    设计步骤

    观念一

    顺序进行:

    1、逻辑架构。

    2、开发架构

    3、数据架构

    4、运行架构

    5、物理架构

    观念二

    5个视图是穿插进行设计的,对复杂系统而言,根本不可能将逻辑视图设计完了后再考虑其它视图。

    笔者观念

    观念一和观念二的情况在现实状况中都可能存在,要根据具体情况具体分析,但总体而言,5视图穿插进行思考更有利于思考的全局性和完整性。

     

    5.4.  如何进行5视图法的设计

     

    以下5视图表格中的工具和方法每个架构师或略有差异,以下仅为参考。

    5.4.1.  逻辑架构

    逻辑架构的重点是考虑软件功能性需求。

     

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    系统功能划分为几个子系统与功能模块?

    系统功能树

    树型结构图

     

    2

    向什么用户提供什么样的功能?

    用例模型

    UML用例图

    体现用户和行为

    3

    每个功能都是怎样的操作流程与分支?

    用例描述

    用例描述表

     

    含输入输出、事件流分析;

    不要有界面描述

    UML活动图

    进行业务流程分析,包括泳道图

    4

    如何通过界面与用户交互?怎样交互?

    鲁棒分析

    鲁棒图

    通过对“用例描述表”进行原文分析法拣出名词和动词

    5

    应当设计哪些类与界面?怎样设计?

    领域模型

    UML类图

     

    6

    与哪些外部系统接口?怎样接口?

    接口描述

    UML类图

     

     

    5.4.2.  开发架构

     

    开发架构重点关注的是开发编码实现方面的问题。

     

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    分层结构设计

    分层架构图(开发架构图)

    各种绘图工具

    好的分层结构支持自动化测试

    2

    开发技术选项

    开发语言

    开发框架

    开发工具

     

    考虑商用产品、开源框架、自研框架

    3

    模块划分

    源码工程;Project目录结构;

    分包(分库)

     

     

    4

    开发规范

    开发/编码规范文档;

     

     

    5

    软件质量属性

    分析和决策结果

     

    考虑运行期和开发期软件质量属性,并权衡利弊进行决策。

     

    5.4.3.  数据架构

     

    数据架构不仅仅要考虑开发中涉及到的数据库,实体模型,也要考虑物理架构中数据存储的设计。

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    数据是集中还是分布存储的?如何考虑分布式存储?

    数据架构图

     

     

    2

    领域模型到数据库表的转换?表结构关系的设计?

    逻辑模型

    物理模型

    ER图

    Power Designer

    Visio

     

    3

    实体如何设计?充血模型和贫血模型?

    UML类图

     

     

    4

    使用什么数据库?关系型还是非关系型?

    选型结果

     

     

     

     

     

    关系型数据库

    非关系型数据库(NoSQL)

    Oracle(首次发行:1980年)

    MySQL(首次发行:1995)

    MS SQL Server(首次发行:1989)

    PostgreSQL(首次发行:1989)

    IBM DB2(首次发行:1983)

    Microsoft Access(首次发行:1992)

    Sybase ASE(首次发行:1987)

    SQLite(首次发行:2000)

    …… 

    MongoDB(首次发行:2009)

    Cassandra(首次发行:2008)

    Apache CouchDB

    Hbase

    Redis

    db4o

    BaseX

    …… 

     

     

     

    5.4.4.  运行架构

     

    运行架构关注的不再是全局而是局部,着重关注那些关键点与难点,常常需要技术攻关与预研。主要考虑控制流、通讯机制、资源争用、锁机制、同步异步、并发、串行,同时也要考虑质量属性。

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    运行:同步vs.异步;并发vs.串行

    考虑开发架构中代码的实现。

     

     

    2

    交互:对象间交互;状态转换

    考虑开发架构的合理性,到类、到接口、到代码。

     

     

    3

    质量:安全;可靠;可伸缩

    考虑开发架构的合理性

     

     

    4

    性能:响应时间;吞吐量

    估算:

    在线人数、并发人数;

    每秒事务量;

    响应时间。

     

     

     

     

     

    5.4.5.  物理架构

     

    物理架构主要考虑硬件选择和拓扑结构,软件到硬件的映射,软硬件的相互影响。

     

    考虑的方面

    产出物

    工具

    说明

    1

    网络方面:网络拓扑;网络设备;安全机制

    拓扑图

    安全规范

     

     

    2

    性能方面:可靠性、可伸缩性

    需要什么样设备性能

     

     

    3

    部署方面:集中式还是分布式;组件部署

    部署图

     

     

     

     

     

     

    6.  一个思考,谁驱动了架构设计?

     

    需求驱动了架构设计?

    质量属性了驱动了架构设计(ADD)?

    领域驱动了架构设计(DDD)?

    风险驱动了架构设计?

    质疑驱动了架构设计?

    ……

    到底是谁驱动了架构设计?我们以船舶设计建造为例,来看这些问题:

    目标和结果

    问题

    回答

    小结

    设计和制造一艘远洋货轮,能经历数月海上颠簸和长途跋涉,并保证货物的安全和完整,最后能顺利抵达目标港口。

    我们为什么要设计和制造这样的大船?

    市场有这个需求;

    获利很丰厚;

    解决就业;

    ……

    不管是外部需求还是内部的需求,都是需求。不正是需求驱动吗?

    如何保证货船能长途航行并经受波涛和风雨?

    船要造的结实;

    鲁棒性

    这些不正是质量属性驱动设计吗?

    引擎设计的强劲;

    性能

    船的燃料充足;

    持续可用性

    装备卫星电话、GPS、雷达等设备

    互操作性

    货物和人员要安全

    安全性

    船舶设计师怎么设计这样的船舶?

    现在都会通过计算机进行船舶的CAD和3D模型设计。

    是不是佷似领域模型驱动了设计?

    造船一定有很多风险吧?

    那是,比如订货方客户有时提出改装船舶的意见(需求变化的风险);有时某些工艺成品率不稳定(质量风险);等等。

    所有可能的风险点在设计时都要考虑到,做好预案,才能保证架构设计的可行性和灵活性,风险驱动了架构设计。

    上面怎么提了那么多问题,其实还有很多问题,比如……

    嗯,你现在有不少疑问了。

    不断的质疑架构设计中可能存在各种问题,有质疑才有思考,才有解决方案,从而推动架构设计的不断完善。

     

    总结:

     

    以上几个方面都能驱动架构设计,并不是零和的规则,而是一个立方体从不同方向看的问题。以上方面有些是指导思想,有些是行动方式,有的兼而有之,阐述方式看似不同,终极目标还是造出大船(实现需求),造出好船(质量属性),怎么造(领域模型),造的顺利(风险控制),挑不出毛病(架构师自己先质疑问题并解决了)。

     

     

    7.  软件架构设计的误区

     

    ● 高开高走落不到实处

    ● 理想与现实需要折中

    ● 遗漏关键性约束与非功能需求

    ● 为虚无的未来埋单而过度设计

    ● 过早做出关键性决策

    ● 客户说啥就是啥成为酱油哥

    ● 埋头干活儿缺乏前瞻性

    ● 架构设计还要考虑系统可测性

    ● 架构设计不要企图一步到位

     

     

    8.  部分参考资料

     

    温昱的《一线架构师实践指南》

     


    注:有网友问:这是自己总结,还是看书总结呢?
    我的回答是:看书是学习的过程,概念是不变真理,架构是工作内容,经验是多年积累,教训是切身体会,内容是自己总结,文章是自己码字,^_^。

    展开全文
  • 架构设计(1)-谈谈架构

    万次阅读 多人点赞 2020-08-14 10:20:07
    1、什么是架构架构本质 在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义,概念是人认识这...

    架构设计学习思维导图: 架构设计系列主要的ADM(架构开发方法)主要基于TOGAF9或者TOGAF9.1来论述。这是个人学习实践和总结笔记,专注并不断积累和更新,努力精进自己。个人拙见,仅供参考。
    1、 架构概述:了解架构基础知识:架构定义、分类、级别、应用架构演进、架构是否合理、架构误区等。
         《谈谈架构》
    2、 原则模式:了解架构模式和设计原则。
         《架构设计原则》
          《架构模式》
    3、 瀑布模式:根据瀑布开发模式,从前期的架构愿景->到架构需求分析->架构设计
          《架构愿景分析》
          《架构需求分析》
          《如何设计一个架构》
    4、 架构三高:架构战术设计主要关注点:高可用、高性能、高效服务治理或者高并发
         《高可用架构设计》
         《高性能设计》
         《分布式服务治理》
    5、 具体知识点:架构实施知识点,框架、组件、限流、容错等知识。
         《分布式链路跟踪》
         《分布式链路跟踪:Zipkin实践》
         《分布式链路跟踪:skywalking实践》
         《我们自研log2跟踪组件》

    一、架构是什么


          在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义, 因为概念是人认识这个世界的基础和用来沟通的手段,如果对架构概念理解不一样,那沟通起来自然不顺畅。

         Linux有架构,MySQL有架构,JVM也有架构,使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构,应该关注哪一个?想要清楚以上问题需要梳理几个有关系又相似的概念:系统与子系统、模块与组建、框架与架构:  

    一、系统与子系统

    系统:泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能独立完成的工作能力的群体。

    子系统:也是由一群关联的个体组成的系统,多半是在更大的系统中的一部分。

    二、模块与组件

    都是系统的组成部分,从不同角度拆分系统而已。模块是逻辑单元,组件是物理单元。

    模块就是从逻辑上将系统分解, 即分而治之, 将复杂问题简单化。模块的粒度可大可小, 可以是系统,几个子系统、某个服务,函数, 类,方法、 功能块等等。

    组件可以包括应用服务、数据库、网络、物理机、还可以包括MQ、容器、Nginx等技术组件。

    三、框架与架构

    框架是组件实现的规范,例如:MVC、MVP、MVVM等,是提供基础功能的产品,例如开源框架:Ruby on Rails、Spring、Laravel、Django等,这是可以拿来直接使用或者在此基础上二次开发。

    框架是规范,架构是结构。

    在TOGAF9是这么定义:一个系统基本的构件(子系统, 模块, 组件),体现在它的各个构件、构件间的相互关系、构件与环境间的关系,以及对系统设计和演进进行治理的原则中。两种含义:
    (1)、一个系统的形式化描述,或指导系统实现的构件级的详细计划。
    (2)、一组构件的结构、构件间的相互关系、以及对这些构件的设计和随时间演进的过程进行治理的一些原则和指导策略

    我在这重新定义架构:软件架构指软件系统顶层结构设计。

    架构是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架: 包括子系统, 模块, 组件. 以及他们之间协作关系, 约束规范, 指导原则.  并由它来指导团队中的每个人思想层面上的一致。

    涉及四方面:

    1、系统性思考的合理决策:比如技术选型、解决方案、成本评估、性价比评估等等。

    2、明确的系统骨架:明确系统有哪些部分组成。

    3、系统协作关系:各个组成部分如何协作来实现业务请求。

    4、约束规范和指导原则:保证系统有序,高效、稳定运行,包括规范、原则、流程等内容。

     

        

    二、架构设计目的


          如果没有架构设计,说明你的系统不够复杂。随着业务的增长,系统由单体应用渐进演化为分布式和微服务化。系统整体的复杂性越来越高,技术团队可能从一个团队变成多个专业化团队。假如没有架构设计,系统定会是一个无序失控的状态,带来的问题:

          1、应用服务的边界不是很清晰:到底该怎么拆分没有一个明确的原则,研发人员为了所谓微服务化而拆分,而不是从当前业务考虑。我们系统出现过类似的情况:一个简单项目拆分成8个子服务,问他为什么这么拆分,说微服务化是为了应对以后扩展方便。结果这个项目从2017年到现在都没有再修改过,接手人宁愿新开发一个项目也不愿重构。

          2、应用服务层次不清晰:导致服务依赖出现网状依赖结构。

          3、系统应用服务跟踪问题:由于微服务化后,服务出现问题后,你很难快速的定位问题。这是我们踩过不少坑,我们使用dubbo服务化,系统一旦出现问题,一推人手忙脚乱。

          4、系统服务监控问题:由于研发人员基本没有服务监控意识,都是出现问题后再想办法如何添加服务监控接口。

           5、技术体系失控问题:不同的开发团队使用不同的技术栈或者组件,造成公司内部的技术架构失控。甚至研发人员为追求时髦新潮技术,拿应用项目来试验新技术。

           。。。。。。  能列举出来还有多各种各样问题。

     

          架构设计的目的是为了解决系统复杂性带来的问题,其本质就是对系统进行有序化地重构以致符合当前业务的发展,并可以快速扩展。从上面架构的定义,也知道架构设计的作用涉及四方面:1、系统性思考的合理决策。2、明确的系统骨架。3、系统协作关系4、约束规范和指导原则。

    架构师通过理解业务,全局把控,选择合适技术,解决关键问题、指导研发落地实施,促进业务发展,提高效率。

     那什么样的系统要考虑做架构设计?  技术不会平白无故的出和自驱动发展起来,而架构的发展和需求是基于业务的驱动。

    1.  需求相对复杂.
    2.  非功能性需求在整个系统占据重要位置.
    3.  系统生命周期长,有扩展性需求.
    4.  系统基于组件或者集成的需要.
    5.  业务流程再造的需要.

     

    三、架构分类


    RUP4+1架构视图

    1995年,Philippe Kruchten在《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文,引起了业界的极大关注,并最终被RUP采纳。即RUP4+1架构方法。该方法主要采用用例驱动,在软件生命周期的各个阶段对软件进行建模,从不同视角对系统进行解读,从而形成统一软件过程架构描述.

    该方法的不同架构视图承载不同的架构设计决策,支持不同的目标和用途:

    逻辑视图:用于描述系统软件功能拆解后的组件关系,组件约束和边界,反映系统整体组成与系统如何构建的过程。关注功能和逻辑层。

    开发视图:描述系统的模块划分和组成,以及细化到内部包的组成设计,服务于开发人员,反映系统开发实施过程。

    物理视图:描述软件如何映射到硬件,反映系统在分布方面的设计,系统的组件是如何部署到一组可计算机器节点上,用于指导软件系统的部署实施过程。

    处理流程视图:用于描述系统软件组件之间的通信时序,数据的输入输出,反映系统的功能流程与数据流程,通常由时序图和流程图表示。关注进程、线程、对象等运行时概念以及相关的并发、同步、通信等问题。

    运用4+1视图方法:针对不同需求进行架构设计

    TOGAF9架构分类

    TOGAF9来对架构分类:

    由于不同架构方法论,定义的架构分类也不同,RUP4+1架构方法主要是以架构生命周期为视角进行描述,而TOGAF9按架构涉及内容维度来描述。因此我结合两者细分为业务架构、应用架构、数据架构、技术架构, 代码架构, 部署架构。

         

         业务架构是战略,应用架构是战术,技术架构是装备。其中应用架构承上启下,一方面承接业务架构的落地,另一方面影响技术选型。 熟悉业务,形成业务架构,根据业务架构,做出相应的应用架构,最后技术架构落地实施。

    1、业务架构(俯视架构)

          包括业务规划,业务模块、业务流程,对整个系统的业务进行拆分,对领域模型进行设计,把现实的业务转化成抽象对象。

           没有最优的架构,只有最合适的架构,一切系统设计原则都要以解决业务问题为最终目标,脱离实际业务的技术情怀架构往往会给系统带入大坑,任何不基于业务做异想天开的架构都是耍流氓。

           所有问题的前提要搞清楚我们今天面临的业务量有多大,增长走势是什么样,而且解决高并发的过程,一定是一个循序渐进逐步的过程。 合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。

    看看京东业务架构(网上分享图)  

         

    2、应用架构(剖面架构,也叫逻辑架构图):

    硬件到应用的抽象,包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。

    类似:

    应用架构:应用作为独立可部署的单元,为系统划分了明确的边界,深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。

    应用架构图关键有2点:

    1、职责划分:   明确应用(各个逻辑模块或者子系统)边界
        1)逻辑分层
        2)子系统、模块定义。
        3)关键类。
    2、职责之间的协作:
     
     1)接口协议:应用对外输出的接口。
       2)协作关系:应用之间的调用关系。

        应用分层有两种方式:

        一种是水平分(横向),按照功能处理顺序划分应用,比如把系统分为web前端/中间服务/后台任务,这是面向业务深度的划分。

        另一种是垂直分(纵向),按照不同的业务类型划分应用,比如进销存系统可以划分为三个独立的应用,这是面向业务广度的划分。

         应用的合反映应用之间如何协作,共同完成复杂的业务case,主要体现在应用之间的通讯机制和数据格式,通讯机制可以是同步调用/异步消息/共享DB访问等,数据格式可以是文本/XML/JSON/二进制等。

         应用的分偏向于业务,反映业务架构,应用的合偏向于技术,影响技术架构。分降低了业务复杂度,系统更有序,合增加了技术复杂度,系统更无序。

         应用架构的本质是通过系统拆分,平衡业务和技术复杂性,保证系统形散神不散。

         系统采用什么样的应用架构,受业务复杂性影响,包括企业发展阶段和业务特点;同时受技术复杂性影响,包括IT技术发展阶段和内部技术人员水平。业务复杂性(包括业务量大)必然带来技术复杂性,应用架构目标是解决业务复杂性的同时,避免技术太复杂,确保业务架构落地。

    3、数据架构

    数据架构指导数据库的设计.  不仅仅要考虑开发中涉及到的数据库,实体模型,也要考虑物理架构中数据存储的设计。

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    数据是集中还是分布存储的?如何考虑分布式存储?

    数据架构图

     

     

    2

    领域模型到数据库表的转换?表结构关系的设计?

    逻辑模型

    物理模型

    ER图

    Power Designer

    Visio

     

    3

    实体如何设计?充血模型和贫血模型?

    UML类图

     

     

    4

    使用什么数据库?关系型还是非关系型?

    选型结果

     

    4、代码架构(也叫开发架构):

    子系统代码架构主要为开发人员提供切实可行的指导,如果代码架构设计不足,就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件,结果公司整体架构设计就会失控。

    代码架构主要定义内容:

    一、代码单元:
            1、配置设计
            2、框架、类库。
    二、代码单元组织:
           1、编码规范,编码的惯例。
           2、项目模块划分
           3、顶层文件结构设计,比如mvc设计。
           4、依赖关系

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    分层结构设计

    分层架构图(开发架构图)

    各种绘图工具

    好的分层结构支持自动化测试

    2

    开发技术选项

    开发语言

    开发框架

    开发工具

     

    考虑商用产品、开源框架、自研框架

    3

    模块划分

    源码工程;Project目录结构;

    分包(分库)

     

     

    4

    开发规范

    开发/编码规范文档;

     

     

    5

    软件质量属性

    分析和决策结果

     

    考虑运行期和开发期软件质量属性,并权衡利弊进行决策。

    最好的样本是参考现有《阿里巴巴Java开发手册》。

     

    5、技术架构

         技术架构:确定组成应用系统的实际运行组件(lvs,nginx,tomcat,php-fpm等),这些运行组件之间的关系,以及部署到硬件的策略。

         技术架构主要考虑系统的非功能性特征,对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。

     系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识,这也是架构设计工作中最为困难的工作。

     

    6、部署拓扑架构图(实际物理架构图):

          拓扑架构,包括架构部署了几个节点,节点之间的关系,服务器的高可用,网路接口和协议等,决定了应用如何运行,运行的性能,可维护性,可扩展性,是所有架构的基础。这个图主要是运维工程师主要关注的对象。

    物理架构主要考虑硬件选择和拓扑结构,软件到硬件的映射,软硬件的相互影响。

     

    考虑的方面

    产出物

    工具

    说明

    1

    网络方面:网络拓扑;网络设备;安全机制

    拓扑图

    安全规范

     

     

    2

    性能方面:可靠性、可伸缩性

    需要什么样设备性能

     

     

    3

    部署方面:集中式还是分布式;组件部署

    部署图

     

     

     

     

    三、架构级别


    我们使用金字塔的架构级别来说明,上层级别包含下层:系统级、应用级、模块级、代码级。

    • 系统级,即整个系统内各部分的关系以及如何治理:分层。

    • 应用级,即单个应用的整体架构,及其与系统内单个应用的关系等。

    • 模块级,即应用内部的模块架构,如代码的模块化、数据和状态的管理等。

    • 代码级,即从代码级别保障架构实施。

    战略设计与战术设计

    基于架构金字塔,我们有了系统架构的战略设计与战术设计的完美结合:

    • 战略设计:业务架构用于指导架构师如何进行系统架构设计。

    • 战术设计:应用架构要根据业务架构来设计。

    • 战术实施:应用架构确定以后,就是技术选型。

     

    四、应用架构演进


    业务架构是生产力,应用架构是生产关系,技术架构是生产工具。业务架构决定应用架构,应用架构需要适配业务架构,并随着业务架构不断进化,同时应用架构依托技术架构最终落地。    

     

    架构演进路程:单体应用->分布式应用服务化-> 微服务

     

    1、单体应用

    企业一开始业务比较简单,只应用某个简单场景,应用服务支持数据增删改查和简单的逻辑即可,单体应用可以满足要求。

    典型的三级架构,前端(Web/手机端)+中间业务逻辑层+数据库层。这是一种典型的Java Spring MVC或者Python Django框架的应用。其架构图如下所示: 

    针对单体应用,非功能性需求的做法:

       1、性能需求:使用缓存改善性能

       2、并发需求:使用集群改善并发

       3、读写分离:数据库地读写分离

      4、使用反向代理和cdn加速

      5、使用分布式文件和分布式数据库

    单体架构的应用比较容易部署、测试, 在项目的初期,单体应用可以很好地运行。然而,随着需求的不断增加, 越来越多的人加入开发团队,代码库也在飞速地膨胀。慢慢地,单体应用变得越来越臃肿,可维护性、灵活性逐渐降低,维护成本越来越高。下面是单体架构应用的一些缺点:

    复杂性高

    以一个百万行级别的单体应用为例,整个项目包含的模块非常多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。可想而知整个项目非常复杂。 每次修改代码都心惊胆战, 甚至添加一个简单的功能, 或者修改一个Bug都会带来隐含的缺陷。

    技术债务: 随着时间推移、需求变更和人员更迭,会逐渐形成应用程序的技术债务, 并且越积 越多。“ 不坏不修”, 这在软件开发中非常常见, 在单体应用中这种思想更甚。 已使用的系统设计或代码难以被修改,因为应用程序中的其他模块可能会以意料之外的方式使用它。

    部署频率低: 随着代码的增多,构建和部署的时间也会增加。而在单体应用中, 每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、 影响范围大、 风险高, 这使得单体应用项目上线部署的频率较低。 而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复,出错率比较高。

    可靠性差: 某个应用Bug,例如死循环、内存溢出等, 可能会导致整个应用的崩溃。

    扩展能力受限: 单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。例如,应用中有的模块是计算密集型的,它需要强劲的CPU; 有的模块则是IO密集型的,需要更大的内存。 由于这些模块部署在一起,不得不在硬件的选择上做出妥协。

    阻碍技术创新: 单体应用往往使用统一的技术平台或方案解决所有的问题, 团队中的每个成员 都必须使用相同的开发语言和框架,要想引入新框架或新技术平台会非常困难。

    2、分布式

    随着业务深入,业务要求的产品功能越来越多,每个业务模块逻辑也都变得更加复杂,业务的深度和广度都增加,使得单体应用变得越来越臃肿,可维护性、灵活性逐渐降低,增加新功能开发周期越来越长,维护成本越来越高。

    这时需要对系统按照业务功能模块拆分,将各个模块服务化,变成一个分布式系统。业务模块分别部署在不同的服务器上,各个业务模块之间通过接口进行数据交互。

    该架构相对于单体架构来说,这种架构提供了负载均衡的能力,大大提高了系统负载能力,解决了网站高并发的需求。另外还有以下特点:

    降低了耦合度:把模块拆分,使用接口通信,降低模块之间的耦合度。

    责任清晰:把项目拆分成若干个子项目,不同的团队负责不同的子项目。

    扩展方便:增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。

    部署方便:可以灵活的进行分布式部署。

    提高代码的复用性:比如Service层,如果不采用分布式rest服务方式架构就会在手机Wap商城,微信商城,PC,Android,iOS每个端都要写一个Service层逻辑,开发量大,难以维护一起升级,这时候就可以采用分布式rest服务方式,公用一个service层。

    缺点:系统之间的交互要使用远程通信,接口开发增大工作量,但是利大于弊。

     

    3、微服务

          紧接着业务模式越来越复杂,订单、商品、库存、价格等各个模块都很深入,比如价格区分会员等级,访问渠道(app还是PC),销售方式(团购还是普通)等,还有大量的价格促销,这些规则很复杂,容易相互冲突,需要把分散到各个业务的价格逻辑进行统一管理,以基础价格服务的方式透明地提供给上层应用,变成一个微内核的服务化架构,即微服务。

          微服务的特点:

    易于开发和维护: 一个微服务只会关注一个特定的业务功能,所以它业务清晰、代码量较少。 开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的,所以整个应用也会被维持在一个可控状态。

    单个微服务启动较快: 单个微服务代码量较少, 所以启动会比较快。

    局部修改容易部署: 单体应用只要有修改,就得重新部署整个应用,微服务解决了这样的问题。 一般来说,对某个微服务进行修改,只需要重新部署这个服务即可。

    技术栈不受限:在微服务架构中,可以结合项目业务及团队的特点,合理地选择技术栈。例如某些服务可使用关系型数据库MySQL;某些微服务有图形计算的需求,可以使用Neo4j;甚至可根据需要,部分微服务使用Java开发,部分微服务使用Node.js开发。

    微服务虽然有很多吸引人的地方,但它并不是免费的午餐,使用它是有代价的。使用微服务架构面临的挑战。

    运维要求较高:更多的服务意味着更多的运维投入。在单体架构中,只需要保证一个应用的正常运行。而在微服务中,需要保证几十甚至几百个服务服务的正常运行与协作,这给运维带来了很大的挑战。

    分布式固有的复杂性:使用微服务构建的是分布式系统。对于一个分布式系统,系统容错、网络延迟、分布式事务等都会带来巨大的挑战。

    接口调整成本高:微服务之间通过接口进行通信。如果修改某一个微服务的API,可能所有使用了该接口的微服务都需要做调整。

    重复劳动:很多服务可能都会使用到相同的功能,而这个功能并没有达到分解为一个微服务的程度,这个时候,可能各个服务都会开发这一功能,从而导致代码重复。尽管可以使用共享库来解决这个问题(例如可以将这个功能封装成公共组件,需要该功能的微服务引用该组件),但共享库在多语言环境下就不一定行得通了。

         
       

    五、衡量架构的合理性


    架构为业务服务,没有最优的架构,只有最合适的架构, 架构始终以高效,稳定,安全为目标来衡量其合理性。

    合理的架构设计:

    1、业务需求角度

    1、能解决当下业务需求和问题

    2、高效完成业务需求: 能以优雅且可复用的方式解决当下所有业务问题

    3、前瞻性设计: 能在未来一段时间都能以第2种方式满足业务,从而不会每次当业务进行演变时,导致架构翻天覆地的变化。

     

    2、非业务需求角度

    (一)、稳定性。指标:

    1. 高可用:要尽可能的提高软件的可用性,我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。

    (二)、高效指标:

    1. 文档化:不管是整体还是部分的整个生命周期内都必须做好文档化,变动的来源包括但不限于BUG,需求。

    2. 可扩展:软件的设计秉承着低耦合的理念去做,注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代,并且支持在适时对架构做出重构。

    3. 高复用:为了避免重复劳动,为了降低成本,我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。

    (三)、安全指标

    1. 安全:组织的运作过程中产生的数据都是具有商业价值的,保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段

    六、常见架构误区


    ●开高走落不到实处

    ● 遗漏关键性约束与非功能需求

    ● 为虚无的未来埋单而过度设计

    ● 过早做出关键性决策

    ● 客户说啥就是啥成为传话筒

    ● 埋头干活儿缺乏前瞻性

    ● 架构设计还要考虑系统可测性

    ● 架构设计不要企图一步到位

    误区1——架构专门由架构师来做,业务开发人员无需关注

    架构的再好,最终还是需要代码来落地,并且组织越大这个落地的难度越大。不单单是系统架构,每个解决方案每个项目也由自己的架构,如分层、设计模式等。如果每一块砖瓦不够坚固,那么整个系统还是会由崩塌的风险。所谓“千里之堤,溃于蚁穴”。

    误区2——架构师确定了架构蓝图之后任务就结束了

    架构不是“空中楼阁”,最终还是要落地的,但是架构师完全不去深入到第一线怎么知道“地”在哪?怎么才能落的稳稳当当。

    误区3——不做出完美的架构设计不开工

    世上没有最好架构,只有最合适的架构,不要企图一步到位。我们需要的不是一下子造出一辆汽车,而是从单轮车 --> 自行车 --> 摩托车,最后再到汽车。想象一下2年后才能造出的产品,当初市场还存在吗?

    误区4—— 为虚无的未来埋单而过度设计

    在创业公司初期,业务场景和需求边界很难把握,产品需要快速迭代和变现,需求频繁更新,这个时候需要的是快速实现。不要过多考虑未来的扩展,说不定功能做完,效果不好就无用了。如果业务模式和应用场景边界都已经比较清晰,是应该适当的考虑未来的扩展性设计。

     

    误区5——一味追随大公司的解决方案

    由于大公司巨大成功的光环效应,再加上从大公司挖来的技术高手的影响,网站在讨论架构决策时,最有说服力的一句话就成了“淘宝就是这么搞的”或者“腾讯 就是这么搞的”。

    大公司的经验和成功模式固然重要,值得学习借鉴,但如果因此而变得盲从,就失去了坚持自我的勇气,在架构演化的道路上迟早会迷路。

     

    误区6——为了技术而技术

    技术是为业务而存在的,除此毫无意义。在技术选型和架构设计中,脱离网站业务发展的实际,一味追求时髦的新技术,可能会将技术发展引入崎岖小道,架构之路越走越难。考虑实现成本、时间、人员等各方面都要综合考虑,理想与现实需要折中。

     

     

    七、架构书籍推荐


     1. 《大型网站技术架构:核心原理与案例分析》

    这是比较早,比较系统介绍大型网站技术架构的书,通俗易懂又充满智慧,即便你之前完全没接触过网站开发,通读前几章,也能快速获取到常见的网站技术架构及其应用场景。非常赞。

     2. 《亿级流量网站架构核心技术》

    相比《大型网站技术架构》的高屋建瓴,开涛的这本《亿级流量网站架构核心技术》则落实到细节,网站架构中常见的各种技术,比如缓存、队列、线程池、代理……,统统都讲到了,而且配有核心代码。甚至连 Nginx 的配置都有!

    如果你想在实现大流量网站时找参考技术和代码,这本书最合适啦。

    3. 《架构即未来》

    这是一本“神书”啦,超越具体技术层面,着重剖析架构问题的根源,帮助我们弄清楚应该以何种方式管理、领导、组织和配置团队。

    4. 《分布式服务架构:原理、设计与实战》

    这本书全面介绍了分布式服务架构的原理与设计,并结合作者在实施微服务架构过程中的实践经验,总结了保障线上服务健康、可靠的最佳方案,是一本架构级、实战型的重量级著作。

    5. 《聊聊架构》

    这算是架构方面的一本神书了,从架构的原初谈起,从业务的拆分谈起,谈到架构的目的,架构师的角色,架构师如何将架构落地……强烈推荐。

    不过,对于没有架构实践经验的小伙伴来讲,可能会觉得这本书比较虚,概念多,实战少。但如果你有过一两个项目的架构经验,就会深深认同书中追本溯源探讨的架构理念。

    6. 《软件架构师的12项修炼》

    大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到,缺乏的知识可以通过决定改变的努力来弥补。

     

    总结参考:

    《大型网站技术架构》、《软件架构师设计》《TOGAF9》

     

     

    展开全文
  • 架构设计(7)—如何设计一个架构

    万次阅读 2020-07-20 19:06:47
    那接下来就是如何着手开始做架构设计。 一、如何开始设计一个架构:方式方法 架构不是像平常写代码一样,对就是对,错就是错,它并无对错之分,是一个取舍的过程。当我们从0开始做架构的时候,的确是比较困难。...

    架构设计学习思维导图: 架构设计系列主要的ADM(架构开发方法)主要基于TOGAF9或者TOGAF9.1来论述。这是个人学习实践和总结笔记,专注并不断积累和更新,努力精进自己。个人拙见,仅供参考。
    1、 架构概述:了解架构基础知识:架构定义、分类、级别、应用架构演进、架构是否合理、架构误区等。
         《谈谈架构》
    2、 原则模式:了解架构模式和设计原则。
         《架构设计原则》
          《架构模式》
    3、 瀑布模式:根据瀑布开发模式,从前期的架构愿景->到架构需求分析->架构设计
          《架构愿景分析》
          《架构需求分析》
          《如何设计一个架构》
    4、 架构三高:架构战术设计主要关注点:高可用、高性能、高效服务治理或者高并发
         《高可用架构设计》
         《高性能设计》
         《分布式服务治理》
    5、 具体知识点:架构实施知识点,框架、组件、限流、容错等知识。
         《分布式链路跟踪》
         《分布式链路跟踪:Zipkin实践》
         《分布式链路跟踪:skywalking实践》
         《我们自研log2跟踪组件》

     

    愿景已经确定架构愿景和目标。
    需求分析明确架构要解决当前什么问题。
    那接下来就是如何着手开始做架构设计。
    一个好的设计:
    1)解决现有需求和问题
    2)把控现实的进度和风险
    3)预测和规划未来,不要过度的设计,从迭代中演进和完善。

     

    前言:架构设计的步骤


    架构设计非常适合使用瀑布模式开发,特别是需要升级架构的系统。

    而TOGAF9的ADM(架构开发方法) ,以需求为中心形成循环的方式表示,即一个阶段的架构工作完成后的成果直接输入到架构工作的后续阶段中去。但总结起来就是:

    瀑布开发模式简单直接,思路清晰,将项目从头到尾划分为不同的阶段,严格定义每个阶段的输入输出,并且十分重视文档。瀑布模型的特点:

    1、简单直接,思路清晰,需求明确。
    2、需要有完善的文档并需要实时更新维护。
    其优点:
    1、可以保证系统在整体上的充分把握,可以保证整个软件产品有较高的质量,保证缺陷能够被提前发现和解决。
    2、可以使系统具备良好的扩展性和可维护性。

     

    一、如何开始设计一个架构:方式方法


    架构不是像平常写代码一样,对就是对,错就是错,它并无对错之分,是一个取舍的过程。当我们从0开始做架构的时候,的确是比较困难。虽然万事开头难,但是一个好的开始相当于成功了一半,会给我们接下去的工作打下结实的基础。

    我的经验步骤是:业务->功能->技术实现->架构综览图

    1、业务架构:确定总体架构,核心流程, 是最上层的战略架构.

           包括业务规划,业务模块、业务流程,对整个系统的业务进行拆分,对领域模型进行设计,把现实的业务转化成抽象对象。

           没有最优的架构,只有最合适的架构,一切系统设计原则都要以解决业务问题为最终目标,脱离实际业务的技术情怀架构往往会给系统带入大坑,任何不基于业务做异想天开的架构都是耍流氓。

           所有问题的前提要搞清楚我们今天面临的业务量有多大,增长走势是什么样,而且解决高并发的过程,一定是一个循序渐进逐步的过程。 合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。

    2、应用架构:确定子系统的功能范围和划分解决方案:

            应用作为独立可部署的单元,为系统划分了明确的边界,深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。

    应用架构图关键有2点:

    1、职责划分:   明确应用(各个逻辑模块或者子系统)边界
         1)逻辑分层
          2)子系统、模块定义。
          3)关键类。
    2、职责之间的协作:
          1)接口协议:应用对外输出的接口。
          2)协作关系:应用之间的调用关系。

    应用分层有两种方式:

        一种是水平分(横向),按照功能处理顺序划分应用,比如把系统分为web前端/中间服务/后台任务,这是面向业务深度的划分。

        另一种是垂直分(纵向),按照不同的业务类型划分应用,比如进销存系统可以划分为三个独立的应用,这是面向业务广度的划分。

         应用的合反映应用之间如何协作,共同完成复杂的业务case,主要体现在应用之间的通讯机制和数据格式,通讯机制可以是同步调用/异步消息/共享DB访问等,数据格式可以是文本/XML/JSON/二进制等。

         应用的分偏向于业务,反映业务架构,应用的合偏向于技术,影响技术架构。分降低了业务复杂度,系统更有序,合增加了技术复杂度,系统更无序。

         应用架构的本质是通过系统拆分,平衡业务和技术复杂性,保证系统形散神不散。

          分久必合,合久必分,结合当前的实际资源情况做出最终的决策,这是整个过程中最耗时的点,它决定着架构的复杂度和开发成本。方式上包括但不限于抽出可重用的功能、功能的组合、拆分粒度更细的功能提高可重用性等等。这一切的决策都要以“恰到好处”为宜。千万不要盲目的跟从微服务之风!千万不要盲目的跟从微服务之风!千万不要盲目的跟从微服务之风!重要的事情说3遍。服务粒度越细,调用链路越复杂,带来的开发成本是否适合团队,是作为一个架构师需要着重考量的点。

         系统采用什么样的应用架构,受业务复杂性影响,包括企业发展阶段和业务特点;同时受技术复杂性影响,包括IT技术发展阶段和内部技术人员水平。业务复杂性(包括业务量大)必然带来技术复杂性,应用架构目标是解决业务复杂性的同时,避免技术太复杂,确保业务架构落地。

     

    3、技术架构: 技术调研, 确定系统核心技术点

    1、技术选型:  根据业务场景, 了解业内的玩法,能不能解决现有问题.  比如使用微服务构建,dubbo,spring cloud.

    2、评估技术成本: 结合业内的玩法与自有技术体系的结合成本,评估使用成本,推广成本.

          例如要使用dubbo,评估现有开发人员能不能hold住,  重构成本有多大.

    3、方案取舍: 技术方案有多种,了解每种方案优缺点, 让大家参与讨论. 

    4、确定系统核心技术方案: 

    技术架构最终是确定组成应用系统的实际运行组件(lvs,nginx,tomcat等),这些运行组件之间的关系,以及部署到硬件的策略。

    技术架构还要考虑系统的非功能性特征,对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。

    系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识,这也是架构设计工作中最为困难的工作。

    4、数据架构:

    数据架构指导数据库的设计

     

    5、架构总览图:

    架构综览图,

    这样能够帮助站在一个更高的角度去考虑架构的演变问题。如果是针对现存项目重新做架构,那么需要把现有项目架构梳理出来,作为我们上面思考过程中的一部分参考信息。

    6,详细设计与实施

    这个架构设计步骤即使就是套路,即方法论,  不论是大系统,还是单个应用系统,  都可以使用这个套路.

    比如我们要设计一个微服务的订单系统:

    1、业务: 确定业务流程:  确定订单关键功能点和流程

    2、应用: 确定订单顶层设计,系统模块,对外暴露哪些接口. 接口协议形式.  

    3、技术: 确定使用哪些技术点: mysql, mongo,是否考虑分表分库. 使用哪些中间件. 

    4、数据: 如何设计表结构. 

    5、详细设计: 

     

     

    技术选型: 是否使用微服务架构设计


    在司成长稳定以后, 业务模式和应用场景边界都已经比较清晰,这个时候最需要对线上业务进行模块划分,系统拆分重构,并做好相关高可用的措施,以保证系统的稳定,安全、高效地运行。这时候可能要考虑引入微服务.

    在引入微服务前你要知道的事:

    1、成本升高

     引入微服务架构,需要对原来单一系统进行拆分,1到100以后多服务的部署会带来成本的升高**

    2、解决分布式事务一致性问题

    以前单一的系统好处很多,一条sql解决完成所有业务逻辑,微服务做完一件事情需要涉及多系统调用,系统间网络的不确定性给结果带来很多不确定性,如今天淘宝的系统,完成一次交易下单需要在上百个系统之间调用,如何保证系统的可靠性,以及核心数据如钱的最终一致性是设计之初就要想明白的,这里大多都要借助中间件来实现。

    3、微服务的逻辑设计原则

    随着不断拆分微服务,以及业务的迭代发展,系统之间极有可能出现混乱调用,所以微服务的顶层设计显得尤为重要,架构师需要搞清楚微服务的架构模型。那核心的设计思想就在于如何进行服务的分层,以及服务的重用,通过分层将服务进行分配,上层服务包装下层服务,下层服务负责原子性的操作,上层服务对下层服务进行业务性的组合编排,一定要理解业务,微服务拆分不是简单的系统组合,再说一遍一定要理解业务,否则上层服务一定会出现大量的交叉调用,系统复杂度会指数级上升,好的微服务架构师一定是业务架构师,基于业务的建瓴,微服务设计三部曲,遵循自下而上的设计原则:

    原子服务

    首先确认最基本业务最维度的原子服务,原子服务定义就是大家都会最大化重用的功能,需要在应用内的闭环操作,没有任何跨其他服务的分支逻辑,杜绝对其他服务的调用,有自己独立的数据存储,作为最底层服务抽象存在,以淘宝为例,卖家数据,卖家数据,订单数据就属于最基本的原子服务。

    服务组合

    在业务场景下,一个功能都需要跨越多个原子服务来完成一个动作。组合服务就是将业务逻辑抽象拆成独立自主的域,域之间需要保持隔离,服务组合会使用到多个原子服务来完成业务逻辑,如淘宝的交易平台会调用用户,商品,库存等系统。

    业务编排

    最外层就是面向用户的业务流程,一个产品化的商业流程需要对组合服务进行逻辑编排来完成最终的业务结果,这个编排服务可以完全是自动化的,通过工作流引擎进行组合自动化来完成特定SOP定义,这对企业应用的自动化流程改进也很有意义。如淘宝类目的双十一活动,通过对不通服务组合进行重用实现不通的营销活动逻辑。

    4、运维管理的复杂度提升

    微服务让应用数量增加很多,链路的集成、测试、部署都成为新的挑战,以前一个war包解决的问题,需要通过多应用发布来完成,发布时服务之间的依赖影响,会导致功能不可用,测试阶段的依赖性可能会让用例跑不下去,这些都会是需要新考虑的问题,需要有平台化的工具来支撑,目前阿里通过aone产品来保证从日常到预发到线上的持续集成交付。

    https://www.toutiao.com/a6587174522653245959/?tt_from=mobile_qq&utm_campaign=client_share&timestamp=1533702418&app=news_article&utm_source=mobile_qq&iid=35493288526&utm_medium=toutiao_ios&group_id=6587174522653245959

    展开全文
  • 架构设计——架构知识体系

    万次阅读 2018-08-23 13:45:58
    架构设计——架构知识体系   1、什么是架构和架构本质 在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。 我们主要针对互联网服server系统...

    架构设计——架构知识体系

     

    1、什么是架构和架构本质


    在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。

    我们主要针对互联网服server系统(类似网站)来定义架构:架构是系统的骨架,支撑和链接各个部分,包括组件、连接件、约束规范,以及指导这些内容设计与演化的原理。

    组件:类似应用服务,独立模块、数据库、nginx等等、

    连接件:分布式调用、进程间调用、调用使用http协议还是tcp协议、组件之间的交互关系、

    约束规范: 定规则做限制:例如设计原则、编码规范等等。

    是系统性地思考,权衡利弊之后在现有资源约束下的“最合理决策”,并由它来指导团队中的每个人思想层面上的一致。

    即架构=组件+交互。

    这类似建筑设计规划,城市总体规划等,其实就是架构,只是应用的场景不同。盖一座小房子,可以拍脑袋干起来,但是当你要盖一座大楼,如果没有一个建筑设计规划,可以想象搭理最后是什么样?

    架构的本质就是对系统进行有序化地重构以致符合当前业务的发展,并可以快速扩展。

    那什么样的系统要考虑做架构设计?

    1. 需求相对复杂.

    2. 非功能性需求在整个系统占据重要位置.

    3. 系统生命周期长,有扩展性需求.

    4.系统基于组件或者集成的需要.

    5.业务流程再造的需要.

     

    2、架构分类


    架构可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构,.

    架构设计——架构知识体系

     

    业务架构是战略,应用架构是战术,技术架构是装备。其中应用架构承上启下,一方面承接业务架构的落地,另一方面影响技术选型。

    熟悉业务,形成业务架构,根据业务架构,做出相应的应用架构,最后技术架构落地实施。

    如何针对当前需求,选择合适的应用架构,如何面向未来,保证架构平滑过渡,这个是软件开发者,特别是架构师,都需要深入思考的问题。

    一、业务架构(俯视架构):

    包括业务规划,业务模块、业务流程,对整个系统的业务进行拆分,对领域模型进行设计,把现实的业务转化成抽象对象。

    没有最优的架构,只有最合适的架构,一切系统设计原则都要以解决业务问题为最终目标,脱离实际业务的技术情怀架构往往会给系统带入大坑,任何不基于业务做异想天开的架构都是耍流氓。

    所有问题的前提要搞清楚我们今天面临的业务量有多大,增长走势是什么样,而且解决高并发的过程,一定是一个循序渐进逐步的过程。 合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。

    看看京东业务架构(网上分享图):

    架构设计——架构知识体系

     

    二、应用架构(剖面架构,也叫逻辑架构图):

    硬件到应用的抽象,包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。

    类似:

    架构设计——架构知识体系

     

    应用架构:应用作为独立可部署的单元,为系统划分了明确的边界,深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。

    应用架构图关键有2点:

    1、职责划分: 明确应用(各个逻辑模块或者子系统)边界

    1)逻辑分层

    2)子系统、模块定义。

    3)关键类。

    2、职责之间的协作:

    1)接口协议:应用对外输出的接口。

    2)协作关系:应用之间的调用关系。

    应用分层有两种方式:

    一种是水平分(横向),按照功能处理顺序划分应用,比如把系统分为web前端/中间服务/后台任务,这是面向业务深度的划分。

    另一种是垂直分(纵向),按照不同的业务类型划分应用,比如进销存系统可以划分为三个独立的应用,这是面向业务广度的划分。

    应用的合反映应用之间如何协作,共同完成复杂的业务case,主要体现在应用之间的通讯机制和数据格式,通讯机制可以是同步调用/异步消息/共享DB访问等,数据格式可以是文本/XML/JSON/二进制等。

    应用的分偏向于业务,反映业务架构,应用的合偏向于技术,影响技术架构。分降低了业务复杂度,系统更有序,合增加了技术复杂度,系统更无序。

    应用架构的本质是通过系统拆分,平衡业务和技术复杂性,保证系统形散神不散。

    系统采用什么样的应用架构,受业务复杂性影响,包括企业发展阶段和业务特点;同时受技术复杂性影响,包括IT技术发展阶段和内部技术人员水平。业务复杂性(包括业务量大)必然带来技术复杂性,应用架构目标是解决业务复杂性的同时,避免技术太复杂,确保业务架构落地。

    三、代码架构(也叫开发架构):

    子系统代码架构主要为开发人员提供切实可行的指导,如果代码架构设计不足,就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件,结果公司整体架构设计就会失控。

    代码架构主要定义:

    一、代码单元:

    1、配置设计

    2、框架、类库。

    二、代码单元组织:

    1、编码规范,编码的惯例。

    2、项目模块划分

    3、顶层文件结构设计,比如mvc设计。

    4、依赖关系

    四、技术架构,也可以叫系统架构

    技术架构:确定组成应用系统的实际运行组件(lvs,nginx,tomcat,php-fpm等),这些运行组件之间的关系,以及部署到硬件的策略。

    技术架构主要考虑系统的非功能性特征,对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。

    系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识,这也是架构设计工作中最为困难的工作。

    架构设计——架构知识体系

     

    五、部署拓扑架构图(实际物理架构图):

    拓扑架构,包括架构部署了几个节点,节点之间的关系,服务器的高可用,网路接口和协议等,决定了应用如何运行,运行的性能,可维护性,可扩展性,是所有架构的基础。这个图主要是运维工程师主要关注的对象。

    架构设计——架构知识体系

     

    3、应用架构


    架构演进路程:

    ->初始阶段:LAMP,部署在一台服务器

    ->应用服务器和数据服务器分离

    ->使用缓存改善性能

    ->使用集群改善并发

    ->数据库地读写分离

    ->使用反向代理和cdn加速

    ->使用分布式文件和分布式数据库

    ->业务拆分

    ->分布式服务

    架构设计——架构知识体系

     

    业务架构是生产力,应用架构是生产关系,技术架构是生产工具。业务架构决定应用架构,应用架构需要适配业务架构,并随着业务架构不断进化,同时应用架构依托技术架构最终落地。

    企业一开始业务比较简单,比如进销存,此时面向内部用户,提供简单的信息管理系统(MIS),支持数据增删改查即可,单体应用可以满足要求。

    随着业务深入,进销存每块业务都变复杂,同时新增客户关系管理,以更好支持营销,业务的深度和广度都增加,这时需要对系统按照业务拆分,变成一个分布式系统。

    更进一步,企业转向互联网+战略,拓展在线交易,线上系统和内部系统业务类似,没必要重做一套,此时把内部系统的逻辑做服务化改造,同时供线上线下系统使用,变成一个简单的SOA架构。

    紧接着业务模式越来越复杂,订单、商品、库存、价格每块玩法都很深入,比如价格区分会员等级,访问渠道(无线还是PC),销售方式(团购还是普通)等,还有大量的价格促销,这些规则很复杂,容易相互冲突,需要把分散到各个业务的价格逻辑进行统一管理,以基础价格服务的方式透明地提供给上层应用,变成一个微内核的SOA架构。

    同时不管是企业内部用户,还是外部顾客所需要的功能,都由很多细分的应用提供支持,需要提供portal,集成相关应用,为不同用户提供统一视图,顶层变成一个AOA的架构(application orientated architecture)。

    4、衡量架构的合理性


    架构为业务服务,没有最优的架构,只有最合适的架构, 架构始终以高效,稳定,安全为目标来衡量其合理性。

    一、稳定性。指标:

    1. 高可用:要尽可能的提高软件的可用性,我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。

    二、高效指标:

    1. 文档化:不管是整体还是部分的整个生命周期内都必须做好文档化,变动的来源包括但不限于BUG,需求。

    2. 可扩展:软件的设计秉承着低耦合的理念去做,注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代,并且支持在适时对架构做出重构。

    3. 高复用:为了避免重复劳动,为了降低成本,我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。

    三、安全指标

    1. 安全:组织的运作过程中产生的数据都是具有商业价值的,保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段

    5、常见架构误区


    误区1——架构专门由架构师来做,业务开发人员无需关注:架构的再好,最终还是需要代码来落地,并且组织越大这个落地的难度越大。不单单是系统架构,每个解决方案每个项目也由自己的架构,如分层、设计模式等。如果每一块砖瓦不够坚固,那么整个系统还是会由崩塌的风险。所谓“千里之堤,溃于蚁穴”。

    误区2——架构师确定了架构蓝图之后任务就结束了:架构不是“空中楼阁”,最终还是要落地的,但是架构师完全不去深入到第一线怎么知道“地”在哪?怎么才能落的稳稳当当。

    误区3——不做出完美的架构设计不开工:世上没有最好架构,只有最合适的架构。我们需要的不是一下子造出一辆汽车,而是从单轮车 --> 自行车 --> 摩托车,最后再到汽车。想象一下2年后才能造出的产品,当初市场还存在吗?

    6、架构知识体系


    架构演进

    • 初始阶段:LAMP,部署在一台服务器
    • 应用服务器和数据服务器分离
    • 使用缓存改善性能
    • 使用集群改善并发
    • 数据库地读写分离
    • 使用反向代理和cdn加速
    • 使用分布式文件和分布式数据库
    • 业务拆分
    • 分布式服务

    架构模式

    • 分层:横向分层:应用层,服务层,数据层
    • 分割:纵向分割:拆分功能和服务
    • 分布式
    • 分布式应用和服务
    • 分布式静态资源
    • 分布式数据和存储
    • 分布式计算
    • 集群:提高并发和可用性
    • 缓存:优化系统性能
    • cdn
    • 方向代理访问资源
    • 本地缓存
    • 分布式缓存
    • 异步:降低系统的耦合性
    • 提供系统的可用性
    • 加快响应速度
    • 冗余:冷备和热备,保证系统的可用性
    • 自动化:发布,测试,部署,监控,报警,失效转移,故障恢复
    • 安全:

    架构核心要素

    • 高性能:网站的灵魂
    • 性能测试
    • 前端优化
    • 应用优化
    • 数据库优化
    • 可用性:保证服务器不宕机,一般通过冗余部署备份服务器来完成
    • 负载均衡
    • 数据备份
    • 自动发布
    • 灰度发布
    • 监控报警
    • 伸缩性:建集群,是否快速应对大规模增长的流量,容易添加新的机器
    • 集群
    • 负载均衡
    • 缓存负载均衡
    • 可扩展性:主要关注功能需求,应对业务的扩展,快速响应业务的变化。是否做法开闭原则,系统耦合依赖
    • 分布式消息
    • 服务化
    • 安全性:网站的各种攻击,各种漏洞是否堵住,架构是否可以做到限流作用,防止ddos攻击。
    • xss攻击
    • sql注入
    • csr攻击
    • web防火墙漏洞
    • 安全漏洞
    • ssl

    7、架构书籍推荐


    1. 《大型网站技术架构:核心原理与案例分析》

    这是比较早,比较系统介绍大型网站技术架构的书,通俗易懂又充满智慧,即便你之前完全没接触过网站开发,通读前几章,也能快速获取到常见的网站技术架构及其应用场景。非常赞。

    2. 《亿级流量网站架构核心技术》

    相比《大型网站技术架构》的高屋建瓴,开涛的这本《亿级流量网站架构核心技术》则落实到细节,网站架构中常见的各种技术,比如缓存、队列、线程池、代理……,统统都讲到了,而且配有核心代码。甚至连 Nginx 的配置都有!

    如果你想在实现大流量网站时找参考技术和代码,这本书最合适啦。

    3. 《架构即未来》

    这是一本“神书”啦,超越具体技术层面,着重剖析架构问题的根源,帮助我们弄清楚应该以何种方式管理、领导、组织和配置团队。

    4. 《分布式服务架构:原理、设计与实战》

    这本书全面介绍了分布式服务架构的原理与设计,并结合作者在实施微服务架构过程中的实践经验,总结了保障线上服务健康、可靠的最佳方案,是一本架构级、实战型的重量级著作。

    5. 《聊聊架构》

    这算是架构方面的一本神书了,从架构的原初谈起,从业务的拆分谈起,谈到架构的目的,架构师的角色,架构师如何将架构落地……强烈推荐。

    不过,对于没有架构实践经验的小伙伴来讲,可能会觉得这本书比较虚,概念多,实战少。但如果你有过一两个项目的架构经验,就会深深认同书中追本溯源探讨的架构理念。

    6. 《软件架构师的12项修炼》

    大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到,缺乏的知识可以通过决定改变的努力来弥补。

    展开全文
  • 高性能微服务架构设计模式

    千人学习 2020-01-06 10:31:43
    本课程是对分布式微服务架构设计模式进行讲解,以亿级QPS的电商网站为例对常见的技术架构进行分析,从高性能,高可用的角度比较各种方案的优劣点,重点讲解使用CQRS模式怎么进行高性能的微服务架构设计,读者学习本...
  • Spring面试题(2020最新版)

    万次阅读 多人点赞 2020-05-06 14:12:13
    Spring框架的设计目标,设计理念,和核心是什么Spring的优缺点是什么?Spring有哪些应用场景Spring由哪些模块组成?Spring 框架中都用到了哪些设计模式?详细讲解一下核心容器(spring context应用上下文) 模块...
  • 目录架构设计请列举出在JDK中几个常用的设计模式?什么是设计模式?你是否在你的代码里面使用过任何设计模式?静态代理、JDK动态代理以及CGLIB动态代理静态代理动态代理cglib代理单例模式工厂模式观察者模式装饰器...
  • Redis面试题(2020最新版)

    万次阅读 多人点赞 2020-05-06 14:14:02
    文章目录概述什么是RedisRedis有哪些数据类型Redis有哪些优缺点Redis的应用场景为什么要用 Redis /为什么要用缓存为什么要用 Redis 而不用 map/guava 做缓存?Redis为什么这么快持久化什么是Redis持久化?...
  • 文章目录架构设计请列举出在JDK中几个常用的设计模式?什么是设计模式?你是否在你的代码里面使用过任何设计模式?静态代理、JDK动态代理以及CGLIB动态代理静态代...
  • Spring MVC面试题(2020最新版)

    万次阅读 多人点赞 2020-05-06 14:12:23
    文章目录概述什么是Spring MVC?简单介绍下你对Spring MVC的理解?Spring MVC的优点核心组件Spring MVC的主要组件?什么是DispatcherServlet什么是Spring MVC框架的控制器?Spring MVC的控制器是不是单例模式,如果是...
  • 软件架构设计-五视图方法论

    万次阅读 2016-05-26 13:10:22
    1.每个人都可以做成为架构设计师 不懂软件的和刚入行的人们一听到架构设计,都认为是非常的高大上课题,是一个遥不可及的领域,一般人是不能做的。听起来云里雾里的,第一印象除了来自微软,阿里这些NB的公司...
  • 系统架构设计

    万次阅读 2018-09-06 14:03:25
    什么是架构架构就相当于我们要盖一栋楼时的框架。系统架构就类似于工程的结构。 一、传统架构 用传统的架构,1000并发量需要2太服务器做tomca集群 但是由于系统用的人越来越多,并发量越来越大待到并发...
  • 系统架构设计师考试经验

    万次阅读 2017-11-02 22:11:28
    系统架构设计师是一个最终确认和评估系统需求,给出开发规范,搭建系统实现的核心构架,并澄清技术细节、扫清主要难点的技术人员。 系统架构设计师考试合格人员能够根据系统需求规格说明书,结合应用领域和技术...
  • 为什么要报考系统架构设计师考试

    万次阅读 多人点赞 2019-11-06 13:44:39
    一、强迫自己,去系统学习软件架构设计的理论,追踪业界架构设计的发展动态。去学习的动力有很多,如为了兴趣,为了工作,为了职位升迁,为了大幅提升薪水等。其实,为了应付考试,通过考试,也是学习知识的一种很好...
  • 架构设计(2)-架构设计原则

    万次阅读 2020-08-09 09:08:54
    如何设计出一个好的架构,不像数据公式或者定律,很难一概而就...一些好的架构设计原则可以确保设计决策在一定程度上能够满足需求。 一、形成架构原则的过程 形成架构原则的过程: 架构原则要SMART ...
  • 系统架构设计师教程.pdf

    千次下载 热门讨论 2020-07-31 00:21:49
    系统架构设计师教程 杨春晖主编 第1章 绪论 第2章 计算机与网络基础知识 第3章 信息系统基础知识 第4章 系统开发基础知识 第5章 软件架构设计 5.1 软件架构概念 5.2 基于架构的软件开发方法 5.3 软件架构风格 ...
  • 软件架构设计---软件架构概述

    万次阅读 2018-09-17 21:25:54
    通俗地讲,软件架构设计就是软件系统的“布局谋篇”。  人们在软件工程实践中,逐步认识到了软件架构的重要性,从而开辟了一个崭新的研究领域。软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构...
  • 一文看懂区块链架构设计

    万次阅读 多人点赞 2016-10-15 11:24:31
    区块链是加密货币背后的技术,是当下与VR虚拟现实等比肩的热门技术之一,本身不是新技术,类似Ajax,可以说它是一种技术架构,所以我们从架构设计的角度谈谈区块链的技术实现。 无论你擅长什么编程语言,都能够参考...
  • 分布式架构设计之电商平台

    万次阅读 2017-02-19 18:48:06
    而软件架构是由业务架构和技术架构两部分组成,因为有了业务结构才会催生出软件架构,进而来满足业务上的需求,所以,在做软件架构设计时,需要分为业务架构设计和技术软件架构设计,二者不可分离哦!那么,接下来就...
  • 架构设计和概要设计

    千次阅读 2014-08-20 11:10:08
    初步再来探讨下架构设计和概要设计的区别和边界问题。先谈下架构设计架构设计包括了功能性架构和技术架构设计两个部分的内容,功能性架构解决业务流程和功能问题,而技术架构解决非功能性需求等问题。两种...
1 2 3 4 5 ... 20
收藏数 882,626
精华内容 353,050
关键字:

架构设计