精华内容
下载资源
问答
  • 技术架构

    千次阅读 2020-05-12 22:55:58
    上一篇文章介绍了什么是架构和架构的分类,作为开发人员的关注点首先是从技术架构开始的,这篇文章的重点就是在技术架构,在技术架构中会涉及到架构风格、架构模式和设计模式,这三者是一种什么关系,这三者和技术...

    上一篇文章介绍了什么是架构和架构的分类,作为开发人员的关注点首先是从技术架构开始的,这篇文章的重点就是在技术架构,在技术架构中会涉及到架构风格、架构模式和设计模式,这三者是一种什么关系,这三者和技术架构又什么关系呢?先通过下图对这些关系有一大致的了解。
    在这里插入图片描述

    架构风格和模式

    主要引自:https://juejin.im/post/5decf93cf265da33d21e6d1d

    架构风格和模式最重要的区分是范围的区别,架构风格非常粗略地告诉我们应该如何组织代码。它的粒度比较大,说明了应用的分层和高层级的模块,这些模块和层次之间如何交互,以及它们的关系;解决反复出现的问题的常见方案就是模式。架构模式解决的就是和架构风格相关的问题。例如,“要实现一个特定层次组合的系统,我们需要哪些类,它们又如何交互”,架构模式对代码的影响相当大,通常会横向地(比如,如何组织同一个层次中的代码)或者纵向地(比如,请求是如何从外层进入到内层处理之后再返回的)影响整个应用。设计模式作用的范围和架构模式不同,它们更局限一些,它们对影响的是代码中某个肯定的部分,对代码的组织影响不多。

    1. 架构风格是最高抽象级别的应用设计; An Architectural Style is the application design at the highest level of abstraction;
    2. 架构模式是实现架构风格的一种方式; An Architectural Pattern is a way to implement an Architectural Style;
    3. 设计模式是解决局部问题的方法。 A Design Pattern is a way to solve a localised problem.

    下图列举了架构模式和架构风格的一些例子:
    在这里插入图片描述

    你会发现,架构风格中有「Multilayered」这个架构风格,架构模式里也有「Multilayered」架构模式!好像分层架构既是架构风格,也是架构模式!实际上架构模式中的「分层架构」是架构风格中的「分层架构」的实际应用。
    更具有说服力的是CS架构风格,可以看到此架构风格后面有个阐述「2-tier, 3-tier, n-tier exhibit this style」,意思是两层架构、三层架构、n层架构都是CS架构风格的一种表现形式。而可以看到,三层架构是一个架构模式!
    这三者整体的关系就如上图那样

    技术架构

    主要引自:https://www.infoq.cn/article/iNbgrQm2liV1EdZeIFyD

    弄明白了上述三者的关系后,我们顺着图向上看,什么是技术架构呢:技术架构 = 解决业务上的技术问题 + 技术方案 + 技术组件 ,下面再细化一下:

    解决业务上的技术问题: 业务除了基本的功能之外,在运行环境中,它也是一种系统,系统还有一种重要的特征就是涌现,什么意思呢?本来平时不是问题的问题现在变成问题了,举一个简单的例子,简单的登录功能,根据用户名和密码在后台进行验证,验证成功就跳转到首页,失败跳到错误页。这个功能太简单不过了,放在普通的业务场景下,这样肯定没有问题,但用在淘宝登录上,你看看,还是之前的操作吗?到这里大家可能就明白了,技术架构一定是解决目前业务上的技术问题,一般而言,技术架构要解决的问题有:高并发、高可用、高性能、高扩展…。

    技术方案:针对上面的技术问题,再设计技术方案,这里的方案应该是系统性的方案,绝对不是用一个或者几个中间件就能解决的问题。所以在设计方案时,要找到问题的本质,拿高并发来讲,笔者认为它是有限的资源应对大量的请求,矛盾很明显了,就是有限的资源和大量的请求,如果去解决这个问题呢?从矛盾出发,分别在资源和请求处理上做文章,这样从前端、网络、后端可以设计出一套系统化的方案出来。

    技术组件:技术方案中会涉及到使用哪些技术组件,如分布式缓存、消息队列、分布式定时任务、网络通信等,这些都是一个个技术组件,技术方案会根据需要选择一个或多个技术组件来完成目标。单纯的技术组件本身是没有技术价值的,它应该是放在相应的业务场景下才会体现出价值来的。

    参考:

    https://www.infoq.cn/article/iNbgrQm2liV1EdZeIFyD
    https://blog.csdn.net/maoyeqiu/article/details/106062438
    https://segmentfault.com/a/1190000016702398
    https://www.jianshu.com/p/d8dce27f279f
    https://juejin.im/post/5decf93cf265da33d21e6d1d
    https://github.com/davideuler/architecture.wechat-tencent

    展开全文
  • 应用架构、业务架构、技术架构和业务流程图详解

    万次阅读 多人点赞 2018-10-09 18:48:32
    应用架构(Application Architecture)是描述了IT系统功能和技术实现的内容。应用架构分为以下两个不同的层次: 企业级的应用架构:企业层面的应用架构起到了统一规划、承上启下的作用,向上承接了企业战略发展方向...

    应用架构

    应用架构(Application Architecture)是描述了IT系统功能和技术实现的内容。应用架构分为以下两个不同的层次:

    企业级的应用架构:企业层面的应用架构起到了统一规划、承上启下的作用,向上承接了企业战略发展方向和业务模式,向下规划和指导企业各个IT系统的定位和功能。在企业架构中,应用架构是最重要和工作量最大的部分,他包括了企业的应用架构蓝图、架构标准/原则、系统的边界和定义、系统间的关联关系等方面的内容。

    单个系统的应用架构:在开发或设计单一IT系统时,设计系统的主要模块和功能点,系统技术实现是从前端展示到业务处理逻辑,到后台数据是如何架构的。这方面的工作一般属于项目组,而不是企业架构的范畴,不过各个系统的架构设计需要遵循企业总体应用架构原则。

    应用架构主要以架构图的方式描述系统的组成和框架,一般从系统功能和系统技术层次两个架构视角进行设计:

    1. 系统功能视角的应用架构图

    ​​​​​

    2. 系统技术层次视角的应用架构图 

    业务架构

    ----摘自《自主变革的基石 制造企业管理技术及SOA实践》

        主要考虑部署,例如你不同的应用如何分别部署,如何支持灵活扩展、大并发量、安全性等,需要画出物理网络部署图。按照应用进行划分的话,还需要考虑是否支持分布式SOA

        每一个典型业务,都可以把它想象为一台运行中的机器,而其中的每个业务组件便是构成这台机器的功能模块。之所以要利用组件来进行业务架构的搭建,正是因为组件具有上述特性,这些特性能确保搭建的典型业务架构图,既完整有效、又无功能冗余,而且有利于今后展开系统架构的组件分析和设计。这样的架构能告诉我们:是由哪些内容相对独立的业务模块构成了这项典型业务。如对其中的每一个业务组件之间的作业关联关系、相互沟通的方式进行研究,就能掌握整个业务架构的协同作业水平;如果对每一个业务组件都采用前述外特性定义的方法加以描述,就能掌握这些组件当前能完成哪些独立的业务内容以及能达成哪些业务目标。本节重点介绍利用业务架构图分析典型业务的分析方法,分析的对象就是业务架构在功能构成方面的完整性和合理性。

       首先,需要表达出当前的典型业务是由哪些业务组件构成的。基本可以断言,大家在开始按上述三个层次描述某个典型业务的构成时,一定会对应该如何定义管理层和决策层的业务组件感到困惑,这是非常自然的反应。因为,至今以来,大家总是在研究执行层的作业方式,不会去、也不敢去研究管理层和决策层的作业能力。但在不远的将来,我们的企业注定要进入业务协同和系统整合的时代,所以,大家现在应该开始学习如何定义和建立管理层和决策层业务组件的具体方法了。

    典型的整车生产企业产品开发业务的业务架构示意图

     

       如典型的整车生产企业产品开发业务的业务架构示意图所示:当我们对于某项典型业务的业务组件的构成进行初步的归纳后,能够得到该项业务的一个整体的框架结构,我们可以称之为“业务架构图”,以及在这个框架内,企业中三个层级的员工在该项业务上分别从事着哪些作业内容。分析执行层的业务作业方式和作业规律,你觉得很正常,但如果让你去分析作为你上司的管理层、甚至决策层的作业方式和作业规律时,你也许会感到有所不安。这种心理反应,实际上正好反映出目前很多企业中的一种能力倒置现象的产生原因。很多人都了解这样的事实,那就是,企业中的很多升职后的中高层领导,在就位后的很长时间内,不能进入应有的管理角色中,这绝对不只是个人能力的差异问题,而主要是因为我们的中高层领导总是习惯地认为:研究执行层的作业方式和规律才是他们的主要职责,而没有注意到自己的作业内容和作业方式在整个作业链条中的重要作用,其结果,自然是管理层和决策层领导们的业绩,只好取决于执行层作业人员的努力程度,这种习惯也导致我们的中高层领导们不会去研究影响自己判断能力和决策能力的技术瓶颈是什么。而很多新出现的现代管理模式,实际上就是为了解决中高层领导们的作业能力问题,或是为了解决三个业务层级之间的信息沟通能力的问题,这也就是为什么业务架构分析人员还必须分析战略层和管理层作业形态的原因。下面将分别说明上述三个不同层次作业组件的特点:

    (1)战略层业务组件

       战略层业务组件自然是用于定义和规范战略层决策人员的业务行为的。那么,哪些人员可以归类于战略决策层之中呢?一般说来,在典型的制造企业中,部长以上的领导应被理解为企业战略决策人员,因为,他们通常已脱离具体的、单一的业务管理,他们通常会被要求在某个综合业务的专业领域提出战略性规划,并按规划进行部署和指挥。但在很多企业中,还设置有经营管理课或战略策划部等机构,其中的一些专门从事为决策层领导进行战略数据分析和提出具体方案的高级管理人员,也应该被认为是战略层业务组件中的业务人员。

     战略层业务组件通常应按如下的作业基准进行设计:

    - 对于特定的典型业务,是否具备有效的战略规划编制和调控能力。

    这里提到的调控能力,是指当企业经营发生重大的内部或外部环境变化时,企业内部是否具备能对既定规划及经营目标做出及时分析和调整的响应机制和具体的作业标准。

    - 制定、发布以及变更经营战略规划的流程和作业规则是否明确。

    这只是一个规范作业流程的问题,在很多企业内部,通常具有手工审批,进行传递的流程,有时存在指令重复、重要度不明、不易追溯等管理问题。

    - 是否能及时、准确地获取相关战略指标的动态统计数据(用于决策)。

    这是直接影响战略层决策能力的重要条件。这里提到的及时和准确,往往可以作为衡量一个企业管理技术水平的标尺。

    - 战略指标数据是否能明确指向具体部门或具体业务组件(用于能力评价)。

    这同样是一项检验企业管理技术水准的重要课题,在此后的第七和第八章中,将对此课题展开详细的讨论。

    - 是否具有根据设置的危机监控标准,及时触发决策机制的系统反应能力(确保决策的及时性)。

    这是一个技术含量最高的课题,任何企业都很难达到这样的水准,只有在管理方法和技术手段方面同时达到很高水准的企业,才能有效展开这一类课题的研究活动。但这一课题显然是所有企业都需要瞄准的目标。

       当然,上述的作业基准未必一定完整和精准,只是按照对一般指挥机构职能的理解来考虑的。例如,企业每年需要设置生产成本控制的战略目标,如经营层的业务人员(实际上是一些领导们)能按图2的成本控制图谱获取所有部门和所有组件的目标达成数据的话,自然就能及时做出相应的评价、指导和决策调整。关于如何实时采集和展现业务状态数据、以及如何设计战略决策信息舱的详细情况,请参见第八章《商业智能和可视化管理》的内容。

    单车成本构成示意图

    (2)管理层业务组件

    由于管理层处于决策层和执行层之间,从信息沟通的角度来说,具有上情下达、下情上报的职责,一般情况下,上情下达比较容易实现,但下情上达则相对困难,存在诸多的管理和技术问题。管理层业务组件应以提升管理层控制业务过程的能力、以及提高管理层和执行层及战略层之间的信息沟通能力为主线进行设计。管理层作业的重点应按如下思路设置:

    - 对于某个典型业务的企业战略,是否具有明确的计划编制、监督实施等作业标准。

    如部门接受了达成企业某个战略,或实现某个企业年度指标的任务时,应该按照既定的作业标准,进行自身业务能力的分析、指标的分解、作业分工以及过程控制方法的确定等作业,以确保该项战略目标或年度绩效指标能按计划展开,并确保其实施过程能得到有效的监控。

    - 相关的典型业务的过程状态是否能有效掌控。

    这一条可以认为是管理层的主要业务方向之一,如一个中层管理人员对如何监控业务过程缺乏最起码的研究,那就基本可以断言,他肯定是一个缺乏最起码业务过程控制能力的管理人员。

    - 对于某些典型业务或某些关键的作业节点,能否实时、有效地评价员工的执行力。

    管理人员之所以需要掌握员工或团队的执行力,不仅仅有利于达成业务目标的正确预测,更重要的是将有利于管理人员发现团队中意愿不足和能力不足的员工,以便及时加以指导。另外,如能实现员工执行力的数据统计,还将有利于事后的正确评价。

    - 对于部门重点业务以及管理改进目标,能否掌握员工知识贡献度的不同。

    能设置符合这一方向的业务组件,其先决条件是必须已经实现了基本有效的知识管理,否则,这样的要求就偏高了一点。作为一个以创新为主的业务部门的管理人员,必须研究如何做才能达成这样的目的,关于这一点,将在第八章中进行详细的介绍。

    - 对于所承担的企业战略指标部分,是否具有实时采集、分析和上报的机制。

    如果管理层职员基本具备这样的意识,就基本上能够得到他们上司的认可,至少能够保持住当前的官帽。如果能够建立这样的机制,具备这样的能力,那就完全不用担心自己的升迁问题了,因为,能够实现及时、准确地“下情上报”的管理人员,已经充分具备了能随时取悦上司的资本。

       总之,从信息沟通的功能来说,设置中层管理业务组件的目的,一是能够掌握企业战略动态,及时编制、和实施部门业务计划;二是要能够实时掌握执行层业务的作业状态(进度、执行力、作业量、知识贡献等)、并能够及时处理、分析执行层的业务统计数据,以便及时对员工进行指导、督促和评价,以及顺利履行按规定向上通报的职责。根据以上思路设置管理层业务组件,从表面来看,似乎主要关注的是中层管理者们处理信息的能力,但大家必须清醒地认识到这样一个事实,那就是:没有充分有效的反映执行层作业状态的信息,管理层就不可能进行有效的控制、指导和评价,作为管理者的能力,也就不可能得到充分地展现。

    (3)执行层业务组件

        执行层业务组件的设计重点,当然首先要关注组件的设置是否有利于实现所属典型业务的目标,其次是希望它能以最少的资源投入来确保业务目标的实现。如果企业单一系统的建设卓有成效,则基本可以认为该企业的执行层业务组件应该是处于一种良好的状态。但在当前加强目标管理、绩效管理的企业,所有执行层组件应该还要考虑是否需要设置向管理层提供信息服务的功能。归纳起来,应考虑以下要素:

    - 是否能确保实现典型业务的业务目标。

    要回答上述问题,必须对典型业务有完整的认识,所以,必须尽量把有利于实现业务目标的业务活动、操作方法以及技术手段都纳入研讨的范围。也许,在考虑如何才能实现典型业务的业务目标时,暂时可以不要过多地去推敲效率的好坏。

    - 实现业务目标的效率如何。

    如果企业对于作业效率有很高的要求,则在设计业务组件时,或许要更多地考虑组件的合并、组件业务流程的连通方式的改进、执行力的监控等有利于提高作业效率的问题。

    - 业务过程失控的危险是否已完全消除。

    企业中的有些业务,如必须需要通过设置控制基准值,并通过逻辑条件或数学运算规则来发现业务过程失控、指标达成失败等现象时、则需要考虑追加自动监控组件,如果没有自动监控的条件,也应明确人工监控的具体方法。

    - 业务状态数据是否可实时采集、统计和发布。

    对于必须控制进程的业务,则通常需要考虑追加进度监控组件,至少应明确关键节点的进度监控方法。

    - 业务组件之间的协同是否顺畅。

     这一条要求是指业务组件之间的流程连通方式、信息共享方式是否符合业务目标的要求,如果不能达到要求,则要追加某种提升协同能力的辅助组件。

        总之,执行层业务组件是实现典型业务目标的骨干部分,而管理层业务组件的合理设置可确保执行层业务过程得到实时的控制,而战略层业务组件则应起到目标调整、资源调整的决策作用。

    在进行上述三个层面的业务组件设置时,如果已经掌握了相对先进的、行业内的最佳实践模式,并对该典型业务进行过组件构成合理性的分析,或者根据日常的业务不良投诉记录,已经掌握了某些组件的问题,那么,在分析和描述该项典型业务时,可明确地表达出该典型业务在构成上的缺失或冗余项,以及当前这些业务组件的业务能力的总体状态。在分析中,最容易发现的是业务组件的缺失项,即一些目前我们还没有开展的业务,而这些业务的开展恰恰有利于企业最新战略的实现。但发现所谓冗余项,则通常是一个不容易完成的任务,因为,大多数员工不会斗胆挑战现有业务存在的合理性,因为大家已经习惯于把时间打发在这些日常业务上了。但作为业务分析人员,建议大家必须时常保持高度的怀疑态度,因为任何业务组件的存在都要消耗资源,为此,任何业务组件都存在压缩、分解乃至取消的可能,如果能通过业务的重组或优化,凸现出某些业务的冗余功能,并最终取消之。这才是分析人员应该加以重点研讨的方向,才是大家更值得骄傲的地方。真所谓“居人之所恶,故几于道”,我们业务分析人员,没有必要对自己始终保持对现实的批判态度而心怀歉疚,反倒应该随时提醒自己,要始终保持对现有业务合理性的怀疑态度,在这方面,做“恶人”比做“好人”,更能体现业务分析人员的职业价值。对于上述的分析结果,自然应在业务架构图中表达出来,具体的表达方式可参见图2-4。在图中,采用的是用色彩区分来表达组件业务能力状态的方法,虽然这种表达方法比较直观,但肯定不是唯一的表达方法,在此建议大家不必拘泥于形式,只要能容易理解即可。

    和最佳实践模式对标或完成调查和分析后的业务热点分析图

        不过,有一点,希望大家注意,上述的架构图是一张企业级的典型业务架构概略图,所以,对于每一个典型业务,都包含了所有相关部门的业务组件。但实际上,我们的很多具体分析,往往只须针对一个部门的业务展开即可。在这种情况下,也可以按照上述的方法编制部门级业务架构图,只是这种架构图在大多数情况下,不需要考虑战略层的组件设计,所以,只采用两层的架构图也是没有问题的。另外,根据需要,对于部门级的业务,还可以编制一种横向按时间顺序展开的架构图,但这种架构图不利于展开全局性的分析,所以,通常不采用,这里就不作详细说明了。

       根据以上两个图例,读者是否不再介意使用‘业务架构’这样的表达方法了呢?为此可以认为,即使是相对抽象的业务也是可以用相对直观的架构形式来表达的。这样的表达方式不仅仅只是为了直观地进行业务的归纳,更重要的是为了直观地表达出现有业务架构的缺陷。图3中,红色的组件表示缺失、冗余或存在严重缺陷的组件,此类组件我们通常称之为“热点组件”(这样的架构图也可称之为热点组件示意图)。红色组件通常是表示尚未实施改进对策的热点组件。粉红色的组件则表示该组件虽有问题,但目前正在对策中。黄色的组件表示存在当前可以默许的缺陷,但随着企业的发展也许需要加以关注的组件,通常其评价的平均得分低于3分。绿色则表明该模块当前运行正常,暂时不需要特别关注的业务。当面对如此直观明了的业务架构图。没有理由不对缺失的和有缺陷的模块部分进行进一步的问题定位分析、并制定改进方案。但怎样才能知道A组件是缺失,应该考虑增设,或B组件有缺陷,需要改进呢?这便是后面的章节中将要重点介绍的核心内容。

    下面这张就是画的比较细的业务架构图

    ​​​​​

    技术架构

    从技术层面描述,主要是分层模型,例如持久层、数据层、逻辑层、应用层、表现层等,然后每层使用什么技术框架,例如Spring、hibernate、ioc、MVC、成熟的类库、中间件、WebService等,分别说明,要求这些技术能够将整个系统的主要实现概括。

    技术框架(technological Framework)是整个或部分技术系统的可重用设计,表现为一组抽象构件及构件实例间交互的方法;另一种定义认为,技术框架是可被技术开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。

    实例图:

    业务流程

    业务流程,是为达到特定的价值目标而由不同的人分别共同完成的一系列活动。活动之间不仅有严格的先后顺序限定,而且活动的内容、方式、责任等也都必须有明确的安排和界定,以使不同活动在不同岗位角色之间进行转手交接成为可能。活动与活动之间在时间和空间上的转移可以有较大的跨度。而狭义的业务流程,则认为它仅仅是与客户价值的满足相联系的一系列活动。

    流程图

    竖式业务流程图就是要业务流从上到下,看起来一目了然。

    竖式业务流程图可以划制成矩阵式流程图,就可以同时说明业务、工作的流程,还可以在流程中明确各自的分工和职责,关键的控制点等。业务流程要重点注意可靠性、资源利用率、反应性、灵活性、较低的管理成本五方面问题。

    综述

    良好的业务流程设计是保证企业灵活运行的关键。清晰的定义业务流程之间的接口,可以降低业务之间的耦合度,使得对局部业务流程的改变不会对全局的流程产生灾难性的后果。

    对整个企业的业务流程进行建模是一个相当复杂而有挑战性的工作,但是并不代表没有方法可循。一般来说,建模需要处理好以下几个方面:

    建立流程

    主要的业务流程是由直接存在于企业的价值链条上的一系列活动及其之间的关系构成的。一般来说包含了采购、生产、销售等活动。 辅助的业务流程是由为主要业务流程提供服务的一系列活动及其之间的关系构成的。一般来说包含了管理、后勤保障、财务等等活动。

    层次关系

    业务流程之间的层次关系反应业务建模由总体到部分、由宏观到微观的逻辑关系。这样一个层次关系也符合人类的思维习惯,有利于企业业务模型的建立。一般来说,我们可以先建立主要业务流程的总体运行过程,然后对其中的每项活动进行细化,建立相对独立的子业务流程以及为其服务的辅助业务流程

    业务流程之间的层次关系一定程度上也反映了企业部门之间的层次关系。为使得所建立的业务流程能够更顺畅的运行,业务流程的改进与企业组织结构的优化是一个相互制约、相互促进的过程。

    合作关系

    企业不同的业务流程之间以及构成总体的业务流程的各个子流程之间往往存在着形式多样的合作关系。一个业务流程可以为其它的一个或多个并行的业务流程服务,也可能以其它的业务流程的执行为前提。可能某个业务流程是必须经过的,也可能在特定条件下是不必经过的。在组织结构上,同级的多个部门往往会构成业务流程上的合作关系。

    进QQ群(779809018)免费领取学习资源,欢迎大家,加入我的微信公众号:代码帮 ,免费分享资源。

    本公众号将秉持活到老学到老学习无休止的交流分享开源精神,汇聚于互联网和个人学习工作的精华干货知识,一切来于互联网,反馈回互联网。
    目前研究领域:大数据、机器学习、深度学习、人工智能、数据挖掘、数据分析。 语言涉及:Java、Scala、Python、Shell、Linux等 。同时还涉及平常所使用的手机、电脑和互联网上的使用技巧、问题和实用软件。 只要你一直关注和呆在群里,每天必须有收获,讨论和答疑QQ群:大数据和人工智能总群(779809018)微信公众号(代码帮)每天分享最新IT、大数据和人工智能新技术。

    展开全文
  • 架构可细分为业务架构、应用架构、技术架构, 业务架构是战略,应用架构是战术,技术架构是装备。 应用架构承上启下: 1、一方面承接业务架构的落地, 2、一方面影响技术选型 应用架构类型:单体式、分布式、SOA...

    架构可细分为业务架构、应用架构、技术架构,

    业务架构是战略,应用架构是战术,技术架构是装备。

    应用架构承上启下:

    1、一方面承接业务架构的落地,

    2、一方面影响技术选型

      应用架构类型:单体式、分布式、SOA架构

    应用架构
        分有两种方式,

          一种是水平分,从功能类型划分,比如把系统分为web前端/中间服务/后台任务,这是面向业务深度的划分。

          一种是垂直分,以业务类型划分,比如ERP系统可以划分为三个独立的应用,这是面向业务广度的划分

         各个应用之间相互协作,主要体现在应用之间的相互通讯机制和数据格式,通讯机制可以同步、异步消息、共享访问等,数据格式是以文本、XML、JSON、二进制等。

    单体式应用
        系统只有一个应用、打包成一个应用;部署在一台机器;在一个DB里存储数据.

        单体式应用采用分层架构,一般为表示层、业务层、数据访问层、DB层,表示层负责用户体验,业务层负责业务逻辑,数据访问层负责DB层的数据存取
        优点:开发、编译、调试一站式、一个应用程序包含所有功能点,容易测试和部署

         缺点:系统逐渐庞大时,代码复杂度高,难以维护,应用扩展水平低,业务和模块职责区分不清晰。

    分布式架构
        分布式应用架构中,相互独立,代码独立开发,独立部署,通过API接口互相通信。通讯协议一般使用HTTP,数据格式是JSON,应用集成方式比较简化。
        优点: 应用内部高内聚,独立开发、测试和部署,应用之间松耦合,业务边界清晰,业务依赖明确,支持大项目并行开发。

        缺点: API接口需求变化,应用就需要重新部署,通信可靠性和数据的封装性相对于进程内调用比较差。

    SOA架构
          SOA也是分布式应用架构一种,
          SOA架构提供配套的服务治理,包括服务注册、服务路由、服务授权、服务降级、服务监控等等,

           SOA架构既体现业务的分,又体现业务的合,更多地从业务整体上考虑系统拆分

          优点:以服务层为主,聚焦核心业务,同时以提供整个系统共享,服务作为独立的应用,独立部署,接口清晰,很容易做自动化测试和部署,

                    服务是无状态的,很容易做水平扩展;通过容器虚拟化技术,实现故障隔离和资源高效利用。

          缺点:系统依赖复杂,给开发/测试/部署带来不便,分布式数据一致性和分布式事务支持困难,一般通过最终一致性简化解决
    --------------------- 
    作者:ejinxian 
    来源:CSDN 
    原文:https://blog.csdn.net/ejinxian/article/details/78150142 
    版权声明:本文为博主原创文章,转载请附上博文链接!

    展开全文
  • 开源大数据技术架构设计

    万人学习 2015-09-23 11:19:44
    主讲: 钱广锐(IBM研究员/技术讲师/教授) 苏再卿(IBM开发组长/工程师/技术讲师) 【课程主题】 开源大数据技术架构设计
  • 技术架构的图片 1.简单的struts+hibernate的开发框架 2.struts+spring+hibernate框架 3.springmvc+spring+mybatis的框架
  • 《前端技术架构与工程》之性能笔记

    万次阅读 多人点赞 2020-06-14 15:17:55
    《前端技术架构与工程》之性能 前言: 《前端技术架构与工程》这本书真的越看越有味。目前写了部分这本书的笔记,共分为三部分做笔记,已写了两篇如下。 《前端技术架构与工程》初次笔记 《前端技术架构与工程》之...

    《前端技术架构与工程》之性能

    前言:

    《前端技术架构与工程》这本书真的越看越有味。目前写了部分这本书的笔记,共分为三部分做笔记,已写了两篇如下。

    《前端技术架构与工程》初次笔记

    《前端技术架构与工程》之编程语言

    今天准备写技术架构部分(编程语言、技术规范、组件化、前后端分离、性能)中的性能部分。

    初次笔记让我从架构师的角度认识前端技术栈,编程语言笔记让我对前端三大件有了新的理解。

    虽然技术规范、组件化、前后端分离里面的知识也重要,但是我这三部分都要了初步了解,勉强够用。唯一性能这一块没有去深入了解,而性能这一块又挺重要的。于是今天特意先做一下性能这一块的笔记。结合《前端技术架构与工程》的第六章以及前端学习梳理 的性能优化部分进行展开。

    我的笔记只是二手资料,详情请自行找资源。

    性能

    性能是衡量软件架构最基本也是最核心的直播之一。在前端领域,HTML5新增的web worker可实现多线程和并行计算以提高运算性能;CSS3的transform 3D借助GPU加速提高动画流畅度;Node.js得益于V8引擎优异的性能表现而普及。互联网产品,尤其是TOC产品,性能是影响用户体验的核心因素之一。了解性能的优化是有必要的。

    在以用户为中心的互联网时代,优秀的用户体验的web应用抢占市场的重要武器,而性能的决定用户体验的核心。加载速度快能够给用户良好的第一印象,流畅的交互是支持功能最具象的要素。

    • 在加载性能上,网络架构层是优化宗旨是减少延迟以提高数据获取的速度,异步script能够减少JavaScript代码对渲染的阻塞从而令HTML文档尽快渲染;
    • 在应用执行期间,熟知浏览器GC策略有助于编写对内存友好的代码,可避免因内存泄漏导致的应用程序交互卡顿甚至死机的现象。

    在《前端技术架构与工程》的性能部分主要从性能评估模型、从URL到图形、内存管理、极限运算性能这四部分进行讲述。

    • 在性能评估模型中:讲性能指标;
    • 从URL到图形:讲如何在加载阶段和可交互阶段优化性能,方法是获取数据和渲染HTML文档;
    • 内存管理:讲在浏览器有限的内存配额下如何优化代码以防止内存泄漏;
    • 极限运算性能:将在大数据处理的项目如何发挥浏览器的极限运算性能;

    性能评估模型

    制定性能评估模板最基本的原则是:对客户端场景参数(设备、浏览器、网络)赋予固定的值,使得应用限定在一致的客户端场景中,然后再进行对比。

    web应用程序的生命周期分两个阶段:一是加载阶段(从输入URL到显示网页的阶段),二是可交互阶段。

    性能评估(贯穿这本书的基本原则,技术服务于业务)分为:加载性能、动态性能、业务性能;

    加载阶段

    加载阶段的性能被称为加载性能。优化加载性能可细分为两个方向:一是从视觉角度提高网站内容的渲染速度,对应白屏时间和首屏时间两项指标;二是从交互角度缩短打开网站到可交互之间的时间间隔,对应可交互节点指标;在这本书第二章将预渲染的时候就有白屏的优化方案。

    可交互阶段

    加载结束,网站进入可交互阶段,由于可交互是动态的,故此阶段的性能定义为动态性能。优化动态性能也有两个方向:一是反馈速度,如新加载内容的加载;二是动画帧率,不过这个不做深入了解,目前占个坑;

    业务性能

    业务性能单独挑出来讲,因为技术服务于商业,商业的优先级远高于技术。在加载阶段,业务性能指标有两个:首次有效绘制和广告可视节点;在可交互阶段,业务性能指标有关键路径渲染。

    从URL到图形

    谈到网页性能优化就不可避免需要了解从URL到页面的具体过程。这个过程不仅和加载相关也和交互相关。学习前端不仅需要学习HTML、CSS、JavaScript,还需要对浏览器的实现过程熟悉,虽然它不能直接提高代码的质量和开发的效率,但是能为方案设计提高坚实的理论基础。

    浏览器的大致架构分为三层:操作系统层、内核层、应用层;

    • 应用层:包含一些可视化的交互模块,如书签管理、窗口管理等;以及一些不可见的数据管理模块,如历史记录等;
    • 操作系统层:提供浏览器所需的系统API,如多线程、文件I/O等;
    • 内核层:浏览器的核心,包括两个部分,一是渲染引擎,包括HTML、CSS、SVG的解释器和JavaScript引擎,以及布局、绘制相关的模块;二是相对底层的功能模块集合,如网络模块、图形库、存储、多媒体解码器;

    其中内核层是优化web应用性能的主要突破点,无论加载性能还是动态性能,其中的关键点就在于网络方面、渲染方面、运算方面;

    浏览器打开URL的完整流程依次是:当前文档卸载、重定向处理、缓存判断、DNS查询、建立TCP连接、HTTP请求/响应处理、HTML文档解析。在这过程中,截止至开始渲染前,浏览器的所有操作实质上就是尝试获取URL对应的信息,这一部分可以定义为Fetch阶段;接收到HTML文档的HTTP响应后,浏览器开始解析和渲染工作,这一阶段可以定义为Render阶段。在Fetch阶段的时间消耗主要取决于网络环境,不受前端代码的影响;在Render阶段的时间消耗受网络环境和前端逻辑代码的双重影响。

    网络

    Fetch阶段。流程为当前文档卸载、重定向处理、缓存判断、DNS查询、建立TCP连接、HTTP请求/响应处理。

    • 当前文档卸载:如果当前为空白页则无此操作;
    • 重定向处理:浏览器在处理重定向上的时间消耗非常大,现实中应当尽量避免。
    • 缓存判断:fetch start。如果有缓存就直接返回缓存数据,没有就继续请求。
    • DNS:DNS server。绝大多数浏览器都有DNS缓存管理功能,可以节省一部分时间。
    • TCP、HTTP请求/响应:web server。获得域名对应的IP后,浏览器便尝试与Web服务器建立TCP连接,成功后随即发生HTTP请求,收到响应数据后便进入Render阶段。

    在上述流程中不难看出,影响耗时的几个重要因素。

    • 缓存,应用缓存和DNS缓存;
    • DNS查询耗时。DNS查询请求优先使用UDP协议,时间消耗非常小;
    • 建立TCP连接的三次握手和慢启动好事。TCP慢启动是一种为了防止阻塞崩溃的安全机制,但是很耗时。
    • 浏览器发出HTTP请求和服务器处理响应数据的耗时。
    • 浏览器下载HTTP响应数据的耗时。这一项取决于网络带宽和URL对应资源的大小。

    为了优化这些耗时。有两个思路。一个是减少RTT的总数量。一个是缩短RTT的时长。减少RTT的总数量的方法有持久连接、并行请求、HTTP combo;缩短RTT的时长的方法是CDN技术。

    此外还有HTTP2.0,但是难以普及,一方面浏览器的兼容性不理想,另一方面是服务器迁移成本太高。所以针对网络的优化策略仍然面向HTTP1.1。其优化策略是

    • 整体架构上:使用持久连接、使用CDN、控制域名数目、无法合并的小体积文件使用HTTP combo;
    • 前端上:压缩文件体积、合并小体积文件(使用字体图标)、合理使用缓存、按需加载、避免不必要的下载。

    渲染

    浏览器在渲染过程在有三种基础数据,及定义网页结构的HTML、描述视觉样式的CSS和承担交互行为的JavaScript,每种数据类型均有对应的解释模块。

    HTML解释器将HTML文档解析为DOM树。CSS解释器将CSS解析为CSSOM,渲染引擎按照CSS选择器规则将DOM与CSSOM关联之后对每个DOM应用样式和布局,最终绘制为可视的UI。

    浏览器在渲染HTML文档期间,每逢遇到非异步的scrip标签则暂停文档后续内容的解析和渲染,待JavaScript文件加载和执行完后才恢复解析。之所以对scrip标签应用阻塞式的解析策略,是英文JavaScript拥有改变HTML文档结构的权限,它会改变DOM树的具体形态,进而影响最终的视觉效果。

    内存管理

    JavaScript是一种拥有GC机制(全GC)的编程语言,GC机制能够使开发者从繁琐的内存管理工作中解脱出来,很大程度上提升开发效率和代码的容错性。但是由于GC属于解释层模块,所以业务开发者几乎没有干预空间,一旦出现内存泄漏便只能靠解释器的GC策略进行调整。

    GC算法

    JavaScript引擎最常见的两种GC算法:标记清除算法、引用计数算法。

    标记清除算法是目前应用较广泛的GC算法之一,绝大多数JavaScript引擎的GC算法都是在标记清除算法基础上的变中,比如V8的标记压缩算法。标记清除算法分为两个阶段:标记阶段和清除阶段。在标记阶段以根节点为起点,使用深度优先搜索算法向下遍历所有对象,随后清除阶段把没标记的对象删除,并且把已标记的对象的标记信息也清除以便下次GC流程正常进行。(补充逻辑部分略)

    引用计数算法是IE6和IE7引擎采用的GC算法,但是目前已经绝迹。虽然这个已经成为了历史产物,但作为对比,有助于理解标记清除算法。略。

    标记清除算法是目前实行JavaScriptGC策略的最佳选择。

    内存泄漏

    在运行应用程序时,计算机管理内存的一般流程是 分配-使用-释放,如此循环。

    内存泄漏指的是一些分配出去的内存空间在使用完后没有释放。这些残留的冗余对象毫无用处却占据内存空间。大量的内存泄漏会造成因内存不足而导致应用程序崩溃甚至宕机。

    造成JavaScript内存泄漏的根本原因是不合理的引用。由于JavaScript引擎的GC操作在语言层面是完全封闭的,开发者没有任何干预的权限,只能通过编写合理的代码以避免发生内存泄漏。

    内存泄漏的处理方法

    避免全局变量。

    在全局作用域内创建对象非常容易引发内存泄漏。并且还有命名冲突、破坏封装性、存在安全隐患等弊端;

    谨慎处理闭包。

    闭包可以在函数内部引用外层作用域的变量,是JavaScript的核心特点之一,但是使用不当很容易造成内存泄漏。

    使用编译工具。

    前两种方法是尽力写出好的代码。第三种方法就是通过前端自动化工具帮助检测,令code smell自动暴露出来。

    极限运算性能

    网络体验最差的地方就是:加载缓慢和操作卡顿。加载缓慢的情况仍然存在,操作卡顿的情况慢慢减少,出了代码质量这种不可控的因素外,造成加载缓慢和操作卡顿的原因分别是网络延迟和浏览器的运算能力。造成网络延迟的因素是多方面的,需要从多方面同时切入优化。造成操作卡顿的原因非常单一,浏览器非常有限的运算能力是唯一的瓶颈。不过现代浏览器的运算能力越来越强了,vue等框架使得最消耗性能的DOM操作实现了轻量化和精细化。

    不过开发者不能毫无顾忌,业务需求的增长速度远超技术的发展,web应用的体量终有一天会增长至如今的几十倍。并且目前复制图形类web应用(如游戏、VR等)已经非常接近浏览器运算能力的瓶颈。

    web worker与并行计算

    单线程的JavaScript无法实现并行计算,当浏览器处理计算量庞大的逻辑时会使用户的任何操作均得不到反馈。web worker是HTML5规范的一部分,借助它可以在浏览器后台创建独立的worker线程运行JavaScript代码,实现多线程并行计算。

    webAssembly

    意思为适合web的汇编语言,是运行与浏览器环境的二进制代码。其定位是应对要求高性能的业务场景,如3D游戏、webVR/AR、音视频等。

    WebGPU

    对于核心聚焦在交互逻辑和UI的前端来说,设计高性能计算的项目计划没有纯粹的数据计算,绝大多数是复杂的图形类应用。基于此,便可以把图形编程领域的诸多优化策略带入前端领域。

    最典型的就是将计算交付给比CPU性能更高的GPU来执行。随着Flash的淘汰,WebGL基本通知复杂图形类web应用的开放市场。webGL的着色器逻辑在GPU中执行,计算性能远高于JavaScript。

    题外话

    《高性能网站建设指南》的借鉴

    其中的14条规则挺有用的,可以借鉴。之后这本书的作者2010年还出版了《高性能网站建设进阶指南》。

    别人的笔记可以借鉴一下:《高性能网站建设指南》笔记

    最好是看原书。

    规则1:尽量减少HTTP请求

    规则2:使用CDN

    规则3:添加Expires头

    规则4:采用Gzip压缩组件

    规则5:将样式表放在顶部(使用link标签将样式表放在文档head中)

    规则6:将脚本放在底部

    规则7:避免CSS表达式

    规则8:使用外部JavaScript和CSS

    规则9:减少DNS查找

    规则10:精简JavaScript

    规则11:避免重定向

    规则12: 删除重复脚本

    规则13:配置ETag(配置或移除ETag)

    规则14:使Ajax可缓存

    有些内容我还看不太懂。不过其中有不少可以借鉴,如

    • 减少HTTP请求数量
    • 将CSS放到head中
    • 将外部脚本置底
    • 资源合并和压缩
    • 避免重复的资源请求
    • 懒加载
    • 代码优化。

    把CSS放在头部的原因是,在加载HTML生成DOM树的时候,就可以同时对DOM树进行渲染。这样可以防止闪跳、白屏或者布局混乱;

    把JavaScript放在后面的原因是,JavaScript可能会改变DOM树的结构,所以需要一个稳定的DOM树。并且JavaScript加载后会立即执行,同时阻塞后面资源的加载。

    最后,本来是想写自己的理解,却没想到这里许多内容都感觉有必要写出来。大家如果感兴趣的话,亲自看书体验更佳。

    更新地址:GitHub

    更多内容请关注:CSDNGitHub

    展开全文
  • 技术架构发展历程

    万次阅读 2018-06-29 16:42:31
    本文摘抄自《大型网站技术架构——核心原理与案例分析》,由李智慧 著 在互联网日益发展的今日,人们每天浏览着大大小小的网站,使用着各式各样的APP,无数的流量在无形中穿梭。那我们是如何判断一个网站或者APP...
  • 常用技术架构总结:包括技术架构、运维架构、产品架构。知识剖析给出了普遍使用的软件技术选型。 目录 知识剖析 技术架构 运维架构 产品架构 知识剖析 技术架构 运维架构 产品架构 设计下载Axure...
  • 漫谈《大型网站技术架构

    万次阅读 2017-04-04 20:37:14
    本文的内容来自阿里巴巴员工李智慧的著作《大型网站技术架构 核心原理与案例分析》,这本书很值得一看,故整理之。
  • 微服务架构设计实践 目 次1 序言2 微服务3 软件架构设计思想4 微服务架构设计实践4.1 项目概述4.2 架构准备阶段4.3 概念架构阶段4.4 细化架构阶段4.4.1 业务架构4.4.2 数据架构4.4.3 应用架构4.4.4 技术架构4.4.5 ...
  • 新浪微博技术架构分析和设计

    万次阅读 2018-04-01 16:35:13
    第一部分:新浪微博技术架构新浪微博在2014年3月公布的月活跃用户(MAU)已经达到1.43亿,2014年新年第一分钟发送的微博达808298条,如此巨大的用户规模和业务量,需要高可用(HA)、高并发访问、低延时的强大后台...
  • 网站技术架构

    千次阅读 2018-11-14 05:44:50
    《大型网站技术架构:核心原理与案例分析》笔记 高可用性 什么是可用性? 可用性(Availablility)是指服务可被有效访问的特性,不是指有用性(Usability)。 能够保证服务永远可用吗? 保证服务永远可用几乎是一件...
  • 视频直播技术架构的新解读

    千人学习 2016-09-06 10:19:58
    音视频直播技术架构教程:视频直播秒开背后的技术与优化经验、webrtc音视频通话技术、直播互动体验、移动直播技术上的坑与优化经验分享。
  • 技术架构评审

    千次阅读 2018-09-11 15:07:49
    我们回到原点,技术架构评审解决什么问题,我觉得实现当下的需求当然重要,这里不再展开,但更重要的是解决未来的需求,就是解决两类问题,一个是业务未来的可扩展性,一个是系统稳定性的可扩展性,总之就是解决需求...
  • 系统架构系列 (六):技术架构要解决什么问题? 技术架构在业内并没有形成约定的统一认识,不同人的理解也不一样,有的人认为引入了中间件就是技术架构。笔者并不这么认为,如果是这样的话,只是将中间件堆在一起...
  • 群里关于技术架构 VS 业务架构的讨论,为便于理解,对对话进行了编排 群里【hazy】同学问: 各位大牛好,大家对技术架构和业务架构这两条道路如何看呢?发展前景和职业规划有什么不同呢? [亮亮]: 技术架构:...
  • 技术架构框架

    千次阅读 2017-09-05 14:50:11
    理想的技术架构框架是,把应用、平台、基础设施相对独立地拆分为以下几层:一、系统层系统层也叫基础设施层。包括系统级的硬、软件两层。底层硬件包括主机、各种服务器、PC、存储设备、网络设备等。第二层系统软件...
  • 搜索引擎的技术架构

    千次阅读 2019-02-01 12:41:45
    搜索引擎的技术架构
  • 豆瓣技术架构

    千次阅读 2015-01-23 17:44:59
    罗马不是一天建成的,豆瓣的技术架构也是随着用户规模的增长一直在持续变化中。洪强宁,2002年毕业于清华大学,现任北京豆瓣互动科技有限公司首席架构师。洪强宁和他带领的技术团队致力于用技术改善人们的文化和生活...
  • 一、系统架构 1、描述 2、示例图 二、软件架构 1、描述 2、示例图 三、总体架构 1、描述 2、示例图 四、业务架构 ...七、技术架构 1、描述 2、示例图 八、物理架
  • AliOS Things 技术架构

    千次阅读 2018-10-13 13:07:39
    AliOS Things 技术架构 AliOS Things 架构可以适用于分层架构和组件化架构。一般来说,从底部到顶部,AliOS Things 包括: 板级支持包(BSP):主要是由SoC供应商开发和维护 硬件抽象层(HAL):比如WiFi ...
  • 如何画出一张合格的技术架构图?

    万次阅读 2019-04-11 09:23:57
    当我们想用一张或几张图来描述我们的系统时,是不是... 画出来的图到底是产品图功能图还是技术图又或是大杂烩? 图上的框框有点少是不是要找点儿框框加进来? 布局怎么画都不满意…… 如果有同样的困...
  • 1、服务器三大技术架构及其发展趋势 2、服务器应用软件的部署架构和特点 【服务器技术架构的三大发展趋势】 Scale-up纵向扩展架构 Scale-out横向扩展架构 Hyper-converged超融合架构 【纵向扩展架构特性】 主要是...
  • 企业的组织架构对技术架构的影响

    千次阅读 2017-06-19 21:19:17
    技术人员往往有闷头挖煤的倾向(闷头做技术架构),而不了解挖煤的上下文背景(企业的业务背景和组织架构),殊不知企业的组织架构和业务背景和技术架构之间有隐含的映射关系,这种关系有时候直接决定了技术架构转型...
  • 知识图谱技术架构

    千次阅读 2019-05-30 15:38:25
    知识图谱技术架构 原文地址:https://mp.weixin.qq.com/s/lBeV6XWzk5bqNGiIMok-zw 数据采集 1、结构化数据 ​ 结构化的数据是指可以使用关系型数据库表示和存储,表现为二维形式的数据。一般特点是:数据以行为单位...
  • Java EE 技术架构分析

    千次阅读 2018-01-03 22:54:31
    1.java EE三层架构,以及架构中包含的技术点 ...2.企业中常见的两种技术组合(这里只列举常见的技术,不代表其他的技术架构不能组合) SSH技术架构:struts2+Spring+Hibernate SSM技术架构:springmvc+spring+mybatis

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 126,454
精华内容 50,581
关键字:

技术架构