精华内容
下载资源
问答
  • 架构设计-谈谈架构

    2019-12-25 11:27:45
    架构设计(1)-谈谈架构 原创我为AI领域做了奉献 发布于2018-11-15 10:39:22 阅读数 419 收藏 展开 分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.csdn.net/jiangjunshow 也欢迎大家...

    架构设计(1)-谈谈架构

    原创我为AI领域做了奉献 发布于2018-11-15 10:39:22 阅读数 419  收藏

    展开

     

    分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.csdn.net/jiangjunshow

     

    也欢迎大家转载本篇文章。分享知识,造福人民,实现我们中华民族伟大复兴!

            

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

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

     

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

     

    1.1、系统与子系统

     

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

     

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

     

    1.2、模块与组件

     

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

     

    1.3、框架与架构

     

    框架是组建的规范,例如:MVC、MVP、MVVM等,是提供基础功能的产品,例如:Ruby on Rails、Spring、Laravel、Django等。

     

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

     

    我再这重新定义架构:软件架构指软件系统的顶层结构。

     

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

     

     

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

     

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

     

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

     

        1. 需求相对复杂.

     

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

     

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

     

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

     

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

     

     

     

     

     

     

     

    2、架构分类

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

     

         

     

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

     

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

     

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

     

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

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

     

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

     

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

     

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

     

           

     

         

     

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

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

     

    类似:

     

     

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

     

    应用架构图关键有2点:

     

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

       1)逻辑分层

       2)子系统、模块定义。

       3)关键类。

    2、职责之间的协作:

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

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

     

        应用分层有两种方式:

     

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

     

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

     

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

     

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

     

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

     

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

     

    2.3、数据架构

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

     

     

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

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

     

    代码架构主要定义:

     

    一、代码单元:

            1、配置设计

            2、框架、类库。

    二、代码单元组织:

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

           2、项目模块划分

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

           4、依赖关系

     

                                                                                        

      

     

    2.5、技术架构

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

     

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

     

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

     

     

     

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

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

     

     

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

     

       

     

     

    3、架构演进路程

     

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

     

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

     

       ->使用缓存改善性能

     

       ->使用集群改善并发

     

       ->数据库地读写分离

     

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

     

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

     

       ->业务拆分

     

       ->分布式服务

     

        

     

     

     

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

     

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

     

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

     

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

     

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

     

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

     

    4、衡量架构的合理性

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

     

    4.1、稳定性。指标:

     

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

     

    4.2、高效指标:

     

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

     

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

     

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

     

    4.3、安全指标

     

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

     

    5、常见架构误区

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

     

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

     

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

     

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

     

    误区5——埋头干活儿缺乏前瞻性

     

     

     

    6、架构知识体系

    6.1架构演进

     

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

     

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

     

    使用缓存改善性能

     

    使用集群改善并发

     

    数据库地读写分离

     

    使用反向代理和cdn加速

     

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

     

    业务拆分

     

    分布式服务

    6.2架构模式

     

    (1)分层:横向分层:应用层,服务层,数据层

     

    (2)分割:纵向分割:拆分功能和服务

     

    (3)分布式 

    分布式应用和服务

    分布式静态资源

    分布式数据和存储

    分布式计算

     

    (4)集群:提高并发和可用性

     

    (5)缓存:优化系统性能 

    cdn

    方向代理访问资源

    本地缓存

    分布式缓存

     

    (6)异步:降低系统的耦合性  

    提供系统的可用性

    加快响应速度

     

    (7)冗余:冷备和热备,保证系统的可用性

     

    (8)自动化:发布,测试,部署,监控,报警,失效转移,故障恢复

     

    (9)安全:

    6.3架构核心要素

     

    (1)高性能:网站的灵魂 

    性能测试

    前端优化

    应用优化

    数据库优化

     

    (2)可用性:保证服务器不宕机,一般通过冗余部署备份服务器来完成 

    负载均衡

    数据备份

    自动发布

    灰度发布

    监控报警

     

    (3)伸缩性:建集群,是否快速应对大规模增长的流量,容易添加新的机器 

    集群

    负载均衡

    缓存负载均衡

     

    (4)可扩展性:主要关注功能需求,应对业务的扩展,快速响应业务的变化。是否做法开闭原则,系统耦合依赖 

    分布式消息

    服务化

     

    (5)安全性:网站的各种攻击,各种漏洞是否堵住,架构是否可以做到限流作用,防止ddos攻击。 

    xss攻击

    sql注入  

    csr攻击

    web防火墙漏洞

     安全漏洞

    ssl

     

     

     

    7、架构书籍推荐

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

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

     

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

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

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

     

    3. 《架构即未来》

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

     

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

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

     

    5. 《聊聊架构》

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

     

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

     

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

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

     

     

    总结参考:

     

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

     

    http://www.rowkey.me/blog/2017/08/24/arch/

     

    https://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650992472&idx=1&sn=ab1234fff936fda3e5cf1f6780cb733d&mpshare=1&scene=23&srcid=1017To1tEophZ2h3McPAESCO##

     

     

    总结参考:

     

    《大型网站技术架构》

     

               

    给我老师的人工智能教程打call!http://blog.csdn.net/jiangjunshow

    ————————————————

    版权声明:本文为CSDN博主「我为AI领域做了奉献」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。

    原文链接:https://blog.csdn.net/skiwnc/article/details/84100128

    展开全文
  • 在上篇文章《软件架构设计之思想篇》中,Relax通过盖房子做了一个类比,聊到了在进行架构设计中我们该从哪些方面去考虑,文中提到了系统、子系统、层次结构、组件、模块、接口和部署等等这样一些抽象的字眼,那大家...

    在上篇文章《软件架构设计之思想篇》中,Relax通过盖房子做了一个类比,聊到了在进行架构设计中我们该从哪些方面去考虑,文中提到了系统、子系统、层次结构、组件、模块、接口和部署等等这样一些抽象的字眼,那大家有没有再深层次的考虑这样的一个问题,就是我们如何将我们考虑的这些点展现出来呢?

    作为一名架构师,你设计的架构其实是要给很多人看的,包括公司领导、产品、开发、测试和运维,那么你该如何把你设计的架构展示给别人呢? 这就是Relax今天想跟大家聊的内容。大家还是不妨先花个两三分钟好好想一想这个问题。

    相信很多小伙伴都已经知道了,答案就是图。所以今天Relax其实聊的主要就是架构设计中的那些图。

    架构设计理论上一般划分五种视图,即逻辑架构视图、开发架构视图、运行架构视图、物理架构视图和运行架构视图。5种架构视图的内容和关系可以看下面两张图:
    五种架构视图
    在这里插入图片描述
    从图中可以看到,五种视图涵盖了逻辑层次划分、接口定义、开发代码组织结构、运行性能设计、运维部署以及数据存储等方方面面。

    在Relax的实际架构设计工作中,逻辑架构视图和物理架构视图考虑得最多,开发架构视图中的代码组织结构,运行架构视图的多线程高并发以及数据架构视图中的数据持久化和存储,主要是作为关键技术点进行分析的,这一点其实是跟所处行业有关。

    除了上面的五种视图以外,Relax还想跟大家聊一下另外一种图,就是UML图,UML包含很多种图,Relax就不在这里一一介绍了,Relax只谈一下自己实际工作中经常用到的五种UML图—类图、构件图、部署图、用例图和序列图。

    类图主要是描述一个类的结构,类是面向对象一个概念,在c语言这种面向过程的语言中,其实也可以按模块的不同功能使用类图来描述这个模块的.c文件和.h文件。

    构件图也可以叫组件图,个人觉得跟上面5图中的逻辑架构视图有点像,主要就是描述系统可以划分的逻辑层次,每个层次包含哪些组件以及子系统包含哪些逻辑层次等等这些内容。

    部署图其实跟上面5图中的物理架构视图有点像,描述的是系统的位置跟硬件形态。

    用例图描述的是系统的输入活动以及系统的自身任务,比如用户会对系统进行什么样的配置操作等等。

    序列图其实就是针对用例图的输入活动,系统中的各个组件针对这个输入如何协同工作,相关组件的一个处理流程的描述。

    好了,软件架构设计中的那些图,Relax今天就聊到这儿,由于都是理论知识,所以可能不是很好理解,不过不要着急,理论是用于指导具体实践的,所以后面Relax会结合今天聊的这些理论知识来谈一个具体的架构设计的案例,相信大家就能很好的理解了。

    想要Relax写出更精彩的文章?那么希望老铁别吝啬你的三连击哦
    1、点赞,可以让更多的人看到这篇文章
    2、关注我的原创微信公众号『Relax聊技术』,第一时间阅读我的文章。
    3、也欢迎关注我的博客哦。
    Relax聊技术

    展开全文
  • 架构设计——架构知识体系 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项修炼》

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

    展开全文
  • 培训过程中,老师用例子说明了一个项目的架构设计的流程。按步骤可以分为: 框架技术的选择应用; 架构平台重构与设计过程; 领域建模; 行为建模; 这四个步骤中,第三步与第四步是最重要的核心。 一. 框架技术的...

    培训过程中,老师用例子说明了一个项目的架构设计的流程。按步骤可以分为:

    1. 框架技术的选择应用;
    2. 架构平台重构与设计过程;
    3. 领域建模
    4. 行为建模

    这四个步骤中,第三步与第四步是最重要的核心。

    一. 框架技术的选择应用

    人们经常对框架与架构的概念混淆。最简单的区分方法,就是可以将架构比作设计图纸,框架比作源码。而框架的选择是架构设计的重要部分,选择框架的一步,被称为架构的概要设计
    市面上有很多已经很成熟的架构,比如 Java 的 SSM 架构,C++ 的 .NET 架构等等。但并不一定说 SSM 架构或者 .NET 架构适用于所有项目。如果分析一个项目的需求之后,发现常用架构不能满足这个新需求,可以选择去 GitHub 等开源社区找同类项目,在开发过程中也可以去 Stack Overflow 论坛请教问题。

    二. 架构平台重构与设计过程

    这个过程是属于产品设计过程,培训老师给了一堆的图和概念,比如 VRM 版本、共用构建组件 (CBB, Common Building Block)、功能分解、模块差异分析、产品平台组合战略等等,都是我看不懂的。最后老师也说,这一部分是属于领导的决策层面的,所以对我并没有什么卵用。跳过忽略。

    三. 领域建模

    领域建模的概念是,对领域内的概念类或者现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。一般采用 UML 中的类图来描述。它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系。

    鲁迅先生曾经说过,讲概念就是不说人话。(手动滑稽 ^_^)
    所以我个人对领域建模浅显的理解为,领域建模过程就是我们分析需求找出对象的过程,同时我们需要把对象之间的关系找出来,最后设计数据表内容。行为建模就是把各种对象之间如何交互的方式设计出来。再换句话说,设计出了领域模型(对象结构)与交互模型(行为),就基本写出了类图和方法

    3.1 UML 类图基本概念

    类之间的关系,主要使用 UML 类图表示。

    在这里插入图片描述

    参考地址:《UML类图与类的关系详解》

    3.2 UML 类图总结

    如果把 UML 类图比较多的种类进行总结,它可以分为五种基本的种类:一对一关联一对多关联多对多关联二元关联继承关联

    3.2.1 一对一关联

    拿房子和人举例,在大学宿舍的情景下,一个学生只能属于一个宿舍,这就是一对一关联的例子。UML 图如下:

    代码如下:

    public class House {
        public House() {}
    }
    
    public class Person {
        private House oneHouse;
        public Person() {
        }
    }
    

    3.2.2 一对多关联

    拿人和房子举例,有钱人都会去买房炒房,也就是说一个人有好几套房产,这就是一对多关联的例子。UML 图如下:

    代码如下:

    public class House {
        public House() {}
    }
    
    public class Person {
        private House[] allHouses;
        public Person() {
        }
    }
    

    3.2.3 多对多关联

    依旧拿大学生和社团举例,一个大学生可以参加好几个社团,一个社团也可以有很多大学生,这就是多对多关联的例子。UML 图如下:

    代码如下:

    public class Student {
        private Vector<Club> clubs = new Vector<>();
        public Student() {}
    }
    
    public class Club {
        private Vector<Student> students = new Vector<>();
        public Club() {}
    }
    

    3.2.4 二元关联

    拿交易来举例,交易需要买家与卖家,但必须有了交易这个事情本身,买家与卖家的关系才能成立,这就是二元关联的例子。同理三元、四元关联也一样。UML 图如下:

    代码如下:

    public class Buyer {
        Trade trades[];
        public Buyer() {}
    }
    
    public class Supplier {
        Trade trades[];
        public Supplier() {}
    }
    
    public class Trade {
        Supplier oneSupplier;
        Buyer oneBuyer;
        public Trade() {}
    }
    

    注:与多对多不同,Trade 作为关联,它也有自己的属性,如交易时间、交易量等。

    3.2.5 继承关联

    以交易为例,买家与卖家都是人,所以卖家与人、买家与人都是继承关系。UML 图如下:

    代码如下:

    public class Person {
        public Person() {}
    }
    
    public class Buyer extends Person {
        public Buyer() {}
    }
    

    四. 行为建模

    行为建模又被称为职责分配。 前面分析过,行为建模的过程就是表述各个领域之间关系的过程。在这个过程中,我们可以使用时序图、通信图等 UML 图,或者鲁棒图等方式来表示行为建模过程。

    4.1 时序图

    时序图是一种强调消息时间顺序的交互图,为读者提供了控制流随着时间推移的清晰的可视化轨迹。如下图所示:

    参考地址:《UML时序图(Sequence Diagram)学习笔记》

    4.2 通信图

    通信图强调的是参加交互对象的组织,为读者提供了在写作对象的结构组织的语境中观察控制流的一个清晰的可视化轨迹。UML2.0 中的通信图基本上就是 UML1 中的协作图。
    通信图并不是很关键的行为建模形式,大部分时间我们是不需要画通信图的。因为如果真的画了一张通信图,基本上就能把代码写完了。所以如果真的画通信图的话,大部分时间只是用来面对大项目理清思路。《UML系列——协作图(通信图)collaboration diagram》一文中用赤壁之战的例子表达了通信图的作用。

    4.3 鲁棒图

    鲁棒图不是 UML 模型的一部分,它是一个强大的草图工具,是结语分析和设计之间的一种有效工具。在实践中,简化的鲁棒图语法将有利于集中精力进行初步设计,而不是关注细节。
    网上查询资料过程中,发现《基于鲁棒图进行概念架构设计》一文中的内容完全就是上课讲的关于鲁棒图的所有内容,这里就不多赘述了。

    五. 总结

    基本上一个项目的架构设计的过程就是上面的四个步骤。最后老师又给我们举了一个项目管理系统的例子。整个项目从获取需求,到最终看到前端页面的整个过程,如下图所示:

    步骤如下所示:

    1. 出现问题,用户提出需求;
    2. 需求师捕获需求并总结(例如使用用户需求捕获卡的形式);
    3. 需求师总结出用户需求特性列表
    4. 建立领域模型
      • 发现类:从用户需求特性列表中,找到合适的名词,将其总结出来,再从这些找出的名词中提取关键内容,往往这些就是领域模型的关键类;
      • 关联分析:即上文提到的找到类之间的联系,画出由 3.2 章节中各模块组成的 UML 类图模型;
      • 职责分析:分析各领域之间的行为,建立各领域之间的联系,向上一步中 UML 类图模型中填充方法;
    5. 建立用例模型
      • 用例图主要是站在人的视角上进行的,即为项目过程中的各种职能角色分配工作;
      • (1) 识别参与者:将参与项目的人员分为各种职能角色(项目经理、开发人员、研发经理、管理层等);
      • (2) 合并特性:将用户需求特性列表中的内容按照各种职能角色进行分析,并将任务分配,分配的每项任务都需要用例覆盖;
      • (3) 描述用例:对每个用例进行描述;
      • (4) 划分用例优先级
      • (5) 为每个用例进行详细的用例描述;
      • (6) 为每个用例绘制时序图;
      • (7) 构建前端用户界面;

    本文总结下来,笔者对架构的理解确实加深了一些。但笔者还是认为,前面这些步骤可能看起来是一个很完整很标准的流程。实际开发过程中难免会出现人手不足、人员分配不当等等等等各种各样的原因,不能做到各岗位各司其职,最后又回到了原始的 “总体 + 后台 + 前台” 的项目结构与开发状态。

    话说这次架构师培训名单上本来是没有我本人的,但是毕竟死猪不怕开水烫,我还是抱着好奇心厚脸皮的向领导申请中途参加培训。参加培训的当天上午,笔者正好刚刚设计了一个项目并简单把思路汇报给了同事龙哥,龙哥正好让我写一个设计文档把思路表达一下,又正好在下午参加的架构师培训中加了这么多通过 UML 图表达项目开发流程的技能点。
    这么多正好,我也不介意多加一笔:把整个培训内容总结完之后,我也正好用自己设计的项目用培训中学到的架构设计方法写一篇设计文档

    Flag 已经立起来了。为什么立 Flag 呢?也许是因为立了 Flag 之后就逃不了了吧哈哈哈 ~

    展开全文
  • 我眼中的架构设计

    2018-11-06 10:16:02
    我眼中的架构设计1. 架构与设计2. 没有最好,只有最适合3. 架构设计 != 设计模式4. 设计思维的养成5. 事例实践5.1. 需求分析5.2. 规范与约束5.3. 细化与评估5.4. 技术选型5.5. 框架搭建5.6. 推进与支持6. 架构设计对...
  • 在上篇文章《软件架构设计之思想篇》中,Relax君通过盖房子做了一个类比,聊到了在进行架构设计中我们该从哪些方面去考虑,文中提到了系统、子系统、层次结构、组件、模块、接口和部署等等这样一些抽象的字眼,那...
  • 今天Relax君想跟大家聊聊软件架构设计方面的内容,很多程序员小伙伴们都将架构师或者技术专家作为自己的职业发展目标,但是大家有没有想过这样的一个问题呢?如果现在让你给你们公司将要开发的一个新产品做一个架构...
  • 架构设计(1)-谈谈架构

    千次阅读 2018-11-15 10:39:22
    架构设计(1)-谈谈架构
  • SOA架构设计

    2019-05-30 11:04:00
    SOA,它是一个面向服务的体系结构,是一个组件模型,它将应用程序的不同功能单元(称为服务)通过...它能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式,能帮助企业系统架构者以更...
  • .NET企业架构设计

    2018-04-11 14:59:59
    软件的需求和质量系统的最终目标有一系列需求描述,这些需求最终决定了系统的架构。需求又分为功能需求和非功能需求:功能性需求是指系统需要做的事情,即系统需要为特定的任务和达到用户的目的提供哪些功能。通常而...
  • 架构设计——架构知识体系(1) 六星教育官博 2020-12-04 10:40:28 41 已收藏 1 分类专栏: 最新技术分享 最后发布:2020-12-04 10:40:28首次发布:2020-12-04 10:40:28 原文链接:...
  • 1、什么是架构架构本质在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。我们主要针对互联网服server系统...
  • 嵌入式软件架构设计

    热门讨论 2021-06-01 18:23:39
    二、为何要进行嵌入式软件架构设计 1、如果没有好的架构,移植将会是一件非常痛苦的事情。 2、如果没有好的架构,复用是不存在的,至少不能最大限度的复用原有的代码。 3、如果没有好的架构,一旦某处修改了,其它...
  • 今天Relax想跟大家聊聊软件架构设计方面的内容,很多程序员小伙伴们都将架构师或者技术专家作为自己的职业发展目标,但是大家有没有想过这样的一个问题呢?如果现在让你给你们公司将要开发的一个新产品做一个架构...
  • 开始之前,假设你已经阅读过我之前撰写的文章“ Architecting Android…The clean way?”。如果还没有阅读过,为了更好地理解这篇文章,...照这么一说,软件是随着时间发展和改变的,是架构上的发展和改变。实际上,好
  • 阅读以下关于软件系统设计的叙述,在答题纸上回答问题1至问题3。...考虑到系统需求对架构设计决策的影响,项目组先列出了可能影响系统架构设计的部分需求如下: (a)用户界面支持用户的个性化定制; (...
  • 首先,了解一下软件架构师的解释,百度百科上,在...主导系统全局分析设计和实施、负责软件构架和关键技术决策的人员软件架构师与软件设计开发的。 这与室内设计师有着一些相似之处,在梦想改造家中,设计师通过与...
  • 架构设计文档有感又一次写架构设计文档,现在至少也是写过6、7次架构设计文档了,每次写架构设计文档自己都有感觉,每次的想法都不同,所以每次的目录结构都有所改动(尽管公司有规范,但我会按自己的理解...
  • 大多数的开发人员在讲DRY (Dont Repeat Yourself) 的时候大多认为DRY是功能和代码的重复,也就是OAOO (Once And Only Once),其实不尽然。面向对象设计提倡的OAOO,强调的是利用面向对象的...DYR更多的是一种架构设计
  • 前几篇将从客户需求、业务分析,模型设计,数据库设计等层面进行了梳理,那么接下来,就需要开始进行系统的架构设计。 就好比盖房子一样,我们需要在搭框架之前,把图纸方案设计好,这样才能循序渐进,一步一步完成...
  • 企业级业务架构设计读书感想 对于非工具类的书,个人觉得最好是可以尝试将文中的观点再次阐述总结,来将书中的思想尽可能选择有益的进行吸收。 业务架构是什么? 就像字面意思一样,是业务的架构,但是这么直白的...
  • 摘要:本文详细介绍了无服务器架构及其优缺点,给正处于架构设计阶段的开发者们一个特别的设计思路。以下是译文。 “无服务器就像是个巫术!我可没有这样说过!等一下!上个周末,我们的一个客户,一家创业公司的...
  • 说起架构,很多人可能会觉得那是很高大上的东西,自己是做不到的;...开发一款app就像建造一幢房屋一样,提前对这幢房屋进行规划,设计,考虑各种因素,然后画出结构图纸,当我们去建造房子的时候才会思路清晰,并且建

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 12,219
精华内容 4,887
关键字:

房子架构设计图