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

    千次阅读 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

    展开全文
  • 大型网站技术架构_核心原理与案例分析_李智慧 PDF 高清
  • 云计算技术架构与实践

    千次下载 热门讨论 2014-11-17 17:29:04
    本书深入浅出地介绍了云计算的基本概念,探讨了云计算的商业模式,展望了云计算对社会的影响及其未来的发展趋势,深入介绍了云计算的关键技术和体系架构,接着对云计算的编程实践进行了清晰讲解,便于读者理论联系...
  • 应用架构(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)是整个或部分技术系统的可重用设计,表现为一组抽象构件及构件实例间交互的方法;另一种定义认为,技术框架是可被技术开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。

    实例图:

    业务流程

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

    流程图

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

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

    综述

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

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

    建立流程

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

    层次关系

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

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

    合作关系

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

    展开全文
  • 技术架构如何做?

    万次阅读 2018-12-02 02:15:05
    作为技术人,大家应该都希望自己能够成为技术专家、架构师。但是在当今纷繁复杂的技术中,如何缕清自己的思路,让自己始终处于一个主动的地位,其实非常重要的。构建自己的知识网,让自己的知识是有条理(整理过后)...

           前段时间在极客时间上学习了《从0开始学架构》。这篇博客通过思维导图的方式对其进行了总结。作为技术人,大家应该都希望自己能够成为技术专家、架构师。但是在当今纷繁复杂的技术中,如何缕清自己的思路,让自己始终处于一个主动的地位,其实非常重要的。构建自己的知识网,让自己的知识是有条理(整理过后)的进行存储,便于日后更加方便的提取使用。

            好,看下总括图吧:

            一,架构是什么?技术本来就是虚的东西,架构就更是了,随着软件复杂度的不断提升,架构才诞生而来。

           二,软件不断提升的复杂度带来的问题,让架构解决了,使得开发人员可以更多的关注业务开发,那么架构的复杂度可想而知,也就是整个软件的技术最复杂的地方了。

           三,既然技术架构这么复杂,我们应该梳理其应该遵循的原则,以及处理时应该有哪些做事的步骤等。

          四,随着互联网的发展,为了提高更好的用户体验度,为了更好应付快速发展的业务,高性能设计,高可用设计、可扩展性设计,在软件架构中占据了核心地位,几乎所有设计都是为了这几个高度抽象的目标努力:

          五,上边说了具体的如何设计,那么当今时代技术的飞速发展,我们该如何站在巨人肩膀上呢?

           六,现实中,往往我们大多会面临如何改前人的代码,架构(如何填坑),对于架构的重构方便,我们应该如何下手呢?有哪些方式方法呢?我们应该注意哪些呢?

          好,上边就是总结思维导图的全部内容,架构的学习道阻且长,我们需要从技术方面、业务方面、经验方面、做人方面、做事方面等不断的学习,不断的积累,不断的思考,不断的总结、不断的反思、不断的成长,来慢慢形成自己的一套行之有效的方式方法路径。好了,加油。继续……

     

         PS:思维导图下载:从0开始学架构-思维导图  也可到我的资源页。

    展开全文
  • 常用技术架构总结:包括技术架构、运维架构、产品架构。知识剖析给出了普遍使用的软件技术选型。 目录 知识剖析 技术架构 运维架构 产品架构 知识剖析 技术架构 运维架构 产品架构 设计下载Axure...

    常用技术架构总结:包括技术架构、运维架构、产品架构。知识剖析给出了普遍使用的软件技术选型。

    目录

    知识剖析 

    技术架构

    运维架构

    产品架构


    知识剖析 

    技术架构

    运维架构

    产品架构

    设计下载Axure文件:https://download.csdn.net/download/boonya/11705011

    展开全文
  • 《前端技术架构与工程》之性能笔记

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

    万次阅读 多人点赞 2018-05-17 10:14:24
    大型网站架构是一个系列文档,欢迎大家关注。本次分享主题:电商网站架构案例。从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型。除具备功能需求外,还具备一定的高性能,高可用,可...
  • 技术架构框架

    千次阅读 2017-09-05 14:50:11
    理想的技术架构框架是,把应用、平台、基础设施相对独立地拆分为以下几层:一、系统层系统层也叫基础设施层。包括系统级的硬、软件两层。底层硬件包括主机、各种服务器、PC、存储设备、网络设备等。第二层系统软件...
  • 支付产品模块是按照支付场景来为业务方提供支付服务。这个模块一般位于支付网关之后,支付渠道之前。 它根据支付能力将不同的支付渠道封装成统一的接口,通过支付网关来对外提供服务...支付产品在支付系统参考架构图...
  • IaaS开源新项目-ZStack技术架构总览

    热门讨论 2015-04-08 11:31:19
    ZStack 是一个全新的开源 IaaS 软件,吸取OpenStack等前辈的经验,针对各种云的问题重头设计了整套架构,旨在解决IaaS复杂度、稳定性、可伸缩性和灵活性等问题。ZStack 0.6 已经提供了大部分 IaaS 的基本功能,包括...
  • 技术架构发展历程

    万次阅读 2018-06-29 16:42:31
    本文摘抄自《大型网站技术架构——核心原理与案例分析》,由李智慧 著 在互联网日益发展的今日,人们每天浏览着大大小小的网站,使用着各式各样的APP,无数的流量在无形中穿梭。那我们是如何判断一个网站或者APP...
  • 一文读懂数据中台技术架构

    千次阅读 2020-11-02 22:11:52
    一文读懂数据中台技术架构 https://www.toutiao.com/i6836923386560512516/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1&timestamp=1603853943&app=news_article&utm_source=...
  • 业务架构、技术架构、部署架构从不同角度描述系统的实现,各有侧重点也有相同之处:业务架构描述功能模块以及功能模块之间的关系,技术架构描述使用的技术,部署架构描述部署逻辑。 1 业务架构:功能模块及功能...
  • 美团技术架构

    万次阅读 2016-04-20 10:30:12
    追求极致:从技术细节看美团架构  很多人认为,电商都没有什么技术含量,没有什么门槛。可是,美团能从千团大战中脱颖而出,成为国内最大的本地生活服务平台,必然不是靠运气。美团网技术委员会主席夏...
  • 大数据之大数据技术架构

    万次阅读 2019-07-11 16:55:29
    最近,中央电视台纪录片频道正在热播的一部纪录片《大数据时代》,细致而生动地讲述了大数据技术在政府治理、民生服务、数据安全、工业转型、未来生活等方面带来的改变和影响。大数据现在已经成了一种全新的思维方式...
  • 微服务架构设计实践 目 次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 ...
  • CMS-项目的技术架构

    千次阅读 2020-01-06 11:47:56
    2 项目的技术架构 2.1 技术架构 学成在线采用当前流行的前后端分离架构开发,由用户层、UI层、微服务层、数据层等部分组成,为PC、App、 H5等客户端用户提供服务。下图是系统的技术架构图: 业务流程举例: 用户...
  • 架构可细分为业务架构、应用架构、技术架构, 业务架构是战略,应用架构是战术,技术架构是装备。 应用架构承上启下: 1、一方面承接业务架构的落地, 2、一方面影响技术选型 应用架构类型:单体式、分布式、SOA...
  • 群里关于技术架构 VS 业务架构的讨论,为便于理解,对对话进行了编排 群里【hazy】同学问: 各位大牛好,大家对技术架构和业务架构这两条道路如何看呢?发展前景和职业规划有什么不同呢? [亮亮]: 技术架构:...
  • Web开发技术架构

    千次阅读 2020-09-24 21:07:05
    Web开发技术架构图 大型web系统架构动态应用,是相对于网站静态内容而言,是指以c/c++、php、Java、perl、.net等服务器端语言开发的网络应用软件,比如论坛、网络相册。1、学习Web开发原理,包括MVC/MTV等Web框架; 2、...
  • IT项目中的应用架构、技术架构、安全架构、部署架构 在日常软件项目开发与实施中,经常会涉及到各种架构图,如应用架构、技术架构、安全架构、部署架构。今天特意将这些架构图整理如下,提供给大家进行学习参考。 一...
  • 微服务总体技术架构体系,一套成熟的体系该有的样子。从上往下:接入层、网关层、业务服务层、支撑服务层、平台服务层、基础设施层。
  • JavaWeb项目技术架构总结

    千次阅读 2019-05-25 17:02:36
    初始搭建 开始的开始,就是各种框架一搭,然后扔到Tomcat容器中跑就是了,这时候我们...由于我们是单体架构,优化架构在短时间内是不现实的,增加机器是一个不错的选择。这时候,我们可能要把应用和数据库服务单独...
  • 中国式SaaS技术架构

    万次阅读 2018-04-13 17:39:58
    架构层面做的强大,满足各个租户的自定义和系统集成。 中国呢,过去的3年已经证明面向中小企业、创业企业基本是不靠谱,所以从去年下半年,大家都纷纷杀入中大型企业、大型企业。这些中国企业,要么要求在他们的...
  • 今日头条技术架构分析

    万次阅读 多人点赞 2018-11-25 17:13:43
    它是今日头条技术架构的核心部分。包括自动推荐与半自动推荐系统两种类型: 1 自动推荐系统 - 自动候选 - 自动匹配用户,如用户地址定位,抽取用户信息 - 自动生成推送任务 这时需要高效率,大并发的推送...
  • 技术架构评审

    千次阅读 2018-09-11 15:07:49
    我们回到原点,技术架构评审解决什么问题,我觉得实现当下的需求当然重要,这里不再展开,但更重要的是解决未来的需求,就是解决两类问题,一个是业务未来的可扩展性,一个是系统稳定性的可扩展性,总之就是解决需求...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,206,136
精华内容 482,454
关键字:

技术架构