技术架构_技术架构图 - CSDN
精华内容
参与话题
  • 应用架构、业务架构、技术架构和业务流程图详解

    万次阅读 多人点赞 2019-10-11 16:00:14
    应用架构(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、大数据和人工智能新技术。

    展开全文
  • 系统整体技术架构

    2020-07-29 14:20:40
    系统整体技术架构
  • 技术架构如何做?

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

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

            好,看下总括图吧:

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

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

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

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

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

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

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

     

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

    展开全文
  • 微服务架构设计实践 目 次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 ...

    微服务架构设计实践
     


    目    次

    4.4.4  技术架构

    4.4.4.1  技术架构定义

            技术架构定义了实现整个系统所需的各种技术,包括开发类、过程管理类、运行环境类、运维支撑类、以及相关技术规范等。

            更确切地说,技术架构描述了在一个可以独立部署的应用系统里,应用、应用平台、基础设施之间的关系。

            在技术架构设计过程中,通常采用分层设计模式,把应用、平台、基础设施相对独立地拆分为以下几层:

            1.系统层,也叫基础设施层,包括系统级的硬件、软件两层:

                底层硬件包括主机、各种服务器、PC、存储设备、网络设备等;

                第二层系统软件包括各种操作系统、数据库等;

            2.平台层,通常包括两层,也可以混合成一层:

                下层是中间件或技术平台。中间件通常指的是厂家在系统层的基础上提供的平台软件,例如IBM的WebSphere、BEA的Tuxedo等;技术平台通常指的是用户自己开发的平台软件;

                第二层是基于中间件之上的开发框架与运行环境生成平台,包括各种生成环境与工具:如建模工具、可视化开发工具、第四代开发语言等;

            3.应用层,包含所有的应用,处于整个技术架构框架的最上层。

            针对不同风格的数据架构和应用架构设计,其实现所需的技术栈是不同的。

            正如序言所述,分行特色业务云平台是分布式服务架构向微服务架构的演进,使用更细粒度的服务和一组设计准则来实现大规模的、复杂的系统设计,并非一个纯粹的微服务架构风格的项目。

            为了项目后期能顺利地迁移到微服务架构,此次的软件开发完全按照微服务架构的标准进行技术标准的制定和技术选型。

            在进行微服务架构设计过程中,主要从以下几个方面考虑:

            

     4.4.4.2  技术架构设计原则

    4.4.4.2.1  系统运行时原则

            应用或服务在运行时,应该提供如下特征:

            

     4.4.4.3  技术架构实践

            分行特色业务云平台在实施过程中,由于项目进度、技术栈、研发团队等方面的约束,基础实施前期采用虚拟服务器集群,后期迁移到行方私有云,技术栈中的其它部分会根据具体情况有所微调,但基本不变。因此,在进行技术架构设计过程中,首先提供一个基于虚拟服务器集群的总体技术体系,然后再提供一个采用云部署的部署方案。

    4.4.4.3.1  总体技术体系

            分行特色业务云平台的总体技术体系包括在项目整个生命周期过程中,软件开发人员需要遵循的技术规范,所使用的开发工具,开发、运行、运维过程中的技术、以及贯穿整个软件生命周期的过程管理工具。

            依据微服务架构的关注点,结合行方目标业务量、研发团队规模、已有技术平台、开发语言约束(Java)等因素,所以,分行特色业务云平台的Java技术栈的技术选型如下:

            1.服务框架

                 选择Dubbo作为分布式服务框架,Tesla平台已经集成Dubbo;

                 Dubbo提供了高性能和透明化的RPC远程服务调用方案,以及服务治理方案;

            2.运行时支撑服务

                 服务注册中心:采用Zookeeper作为服务注册中心;

                 服务网关:自主实现API网关,实现通讯协议解析,安全认证,流量控制,数据转换,协议转换等功能;

                 配置中心:自主实现基于DisConf的配置中心;

                 负载均衡:基于F5的硬负载,Dubbo提供的软负载等;

            3.服务部署平台

                 支持灰度发布;

                 基于行方私有云的容器调度、租户资源治理;

                 半自动化的服务发布流程(后面详细描述);

            4.服务运行平台

                 第一阶段基于Linux虚拟机的集群部署;

                 后期迁移到私有云,基于docker容器集群部署;

            5.服务安全

                 基于角色的认证授权机制;

                 引入数字证书,对通讯数据进行签名、验签,保证用户的身份认证、通讯信息的完整性;

                 通过数字签名和数字时间戳,保证业务操作的不可抵赖性;

            6.服务容错

                 基于Dubbo实现服务的开关、限流、降级、超时等;

            7.服务监控

                 基于Logback分级记录系统运行日志、业务操作日志,并定期同步到日志归档平台;

                 通过自定义Spring注解实现服务调用链日志记录;

                 集成到Tesla监控平台,实现分行特色业务云平台运行状态的监控;

            8.后台服务

                 引入ZDAL,实现分布式数据访问层,支持分库分表;

                 基于Quartz自主实现自动任务调度;

                 自主实现本地内存缓存,采用Redis实现分布式数据缓存;

            综合以上内容,分行特色业务云平台的总体技术体系如下图所示:

             

            1.开发工具

            此次主要采用的开发工具如下:

                 IDE:Spring Tool Suite;

                 SDK:JDK1.7及以上;

                 单元测试:Junit、Mockito;

                 集成测试:待定;

                 性能测试:JMeter、LoadRunner;

                 代码生成器:自主研发的CodeGenerator;

                 业务流程设计器:自主研发的Activit Designer;

            2.技术规范

            此次涉及的技术规范主要如下:

                 平台开发规范;

                 接口设计规范;

                 数据库设计规范;

                 统一返回码规范;

                 日志规范;

                 过程管理规范;

                 QA规范;

                 投产运维规范;

            3.开发、运行环境

            一、 WEB前端开发框架

            WEB前端采用Tesla平台自主研发的TESLA-UI框架,该框架采用时下比较流行的MVVM设计模式,使用SeaJS进行JavaScript模块化管理,提供了基于JQuery的UI组件库和UI皮肤库,以及基于HTML的布局模板,适用于企业管理类型前台页面的开发。

            二、 服务开发框架 

            后台服务采用行方自主研发的Tesla平台,该平台采用“微内核”+“组件”设计,稳定的内核保证系统的健壮性,丰富的组件保证系统的灵活性、扩展性。

            TESLA定义了良好的扩展机制和统一的模块交互机制,能够定制化地为应用系统提供各种基础功能,例如:IoC容器、数据访问、MVC框架、缓存、工作流、服务编排、系统集成、服务治理等等。

            TESLA融合了诸多互联网领域的技术,包括高并发的Web服务端技术(WebX、SpringExt)、服务化架构下的服务治理技术(Dubbo)、大数据量分库分表技术(ZDAL)、分布式缓存技术(Redis、Memcached)、高性能数据源连接池技术(Druid)、分布式配置管理技术(Disconf)等等。

            另外,TESLA具有应对金融领域业务系统复杂性的能力,在业务快速集成与分布式事务数据一致性处理上做了很多支持。

            TESLA框架分层如下:

            1.渠道层:负责接收客户端发来的请求,不同的协议可以启用不同的渠道,比如有http、webservice、Socket等。

            2.业务功能层:抽象业务功能处理的概念,Function代表一个业务功能,Filter是过滤器(可以设置在不同的作用域,比如Function级别,Function组级别,整个应用级别)、Action是Function中执行的每一个活动,Context是整个架构的数据载体,PamameterProcesser是参数处理器,用于参数进行校验和转换。

            3.服务成层:Tesla采用“微内核”+“组件”设计,所有的服务组件都在这一层,都是开发中常用的一些基础功能,比如分页、缓存、工作流引擎、服务编排引擎、序列号生成器等。

            4.集成层:负责和外部系统进行交互,RPC调用、Ftp、消息中间件等,同时纳入到服务治理体系。

            5.开发工具集:全栈代码生成器,服务客户端代码生成器、业务流程设计器等。

            6.数据访问层:负责DAO数据库SQL操作(基于Mybatis)、管理数据库连接池、事务、基于ZDAL进行分库分表。

            7.基础设施:面向运维的一些支持设施,无需额外开发,如统一应用监控中心、配置管理中心、服务注册中心、异常处理平台集成等。

            三、 中间件和技术平台

            1.应用服务器

                 开发环境、单元测试环境:Tomcat7及以上;

                 集成测试环境、UAT测试环境、生产环境:Weblogic10;

            2.WEB服务器

                 开发环境、单元测试环境:Tomcat7及以上;

                 集成测试环境、UAT测试环境、生产环境:Apache,Nginx;

            3.分布式数据一致性管理

                 Zookeeper;

            4.缓存

                 Redis

            5.容器

                 Docker

            6.JVM

                 开发环境、单元测试环境:Sun Hotspot 1.7及以上;

                 集成测试环境、UAT测试环境、生产环境:JRockit 7及以上;

            四、系统软件平台

                1. 数据库

                    总行:DB2 10及以上;

                    分行:根据分行具体情况任选其一:DB2、MySQL、Oracle;

                2. 操作系统

                    DB2数据库服务器:IBM AIX;

                    其它服务器:SUSE Linux;

            五、 系统硬件平台

                1. 使用行方现有的虚拟化服务器;

            4.过程管理

            此次主要采用的过程管理工具如下:

                 项目构建:Maven;

                 版本控制:SVN;

                 构件仓库:Nexus;

                 缺陷跟踪:JIRA;

                 代码审查:FishEye、Crucible;

                 知识管理:Confluence;            

                 持续集成、持续交付:Bamboo;

    4.4.4.3.2  持续集成、持续交付

            上述章节介绍了分行特色业务云平台的总体技术体系,在此,针对贯穿整个项目实施过程,保证项目质量、项目实施进度,减少项目实施风险的软件过程管理中的持续集成和持续交付的流程进行详细地说明,以便指导和约束整个软件实施过程。

            正如本文《软件架构设计思想》章节中描述的,架构的本质就是通过“分“与”合“的手段,对系统进行有序化重构,不断减少系统无序的程度,使系统不断进化。

            从一个简单的单体应用到分布式应用,再到更为复杂的微服务架构,除了关心如何拆、怎么拆的问题,还必须关注如何控制拆的风险、如何保证代码质量、如何保证功能符合用户需求等。

            解决上述问题的手段就是集成,从一开始就集成,并且不断的集成,反复的将拆分的子系统、模块、组件重新组合,看看是否能够顺利组合起来,并且保证功能的不变。

            实现上述不断地集成以及成果物交付的过程就是持续集成和持续交付:

            1.持续集成:指对代码的提交,构建,测试的过程,这是一个持续、反复的过程。

            2.持续交付:指将集成好的交付物,例如war、jar或者容器镜像,部署在联调环境,或者预发环境的过程。

            以下是本项目采用的一个持续集成、持续交付的过程,研发团队在项目实施过程中要严格遵守:
             

            持续集成、持续交付的基本流程如下:

                1. 代码开发,完成分配的任务。

                2. 每天提交代码,降低代码集成的风险。采用SVN的提交方式,后提交者有责任去merge,保证代码的编译通过和测试通过。

                3. 专人定期审核提交的代码,把控代码质量。

                4. 代码审核完毕之后,触发编译过程,完成代码编译。

                5. 编译完成,进行单元测试。要求每个类都要有单元测试,并且单元测试覆盖率要达到一定的指标。单元测试要有带Mock的模块内的集成测试。如果单元测试不通过,则统计后发邮件,抄送所有的人。

                6. 单元测试通过以后,上传成果物(war、jar或其它)至Nexus私服。

                7. 如果采用私有云,并且使用docker容器,则需要编译Dockerfile,使用Docker镜像作为交付,能够实现更好的环境一致性,保证原子的升级和回滚。

                8. 每天下班前,当天的代码需要提交到库中去,晚上会做一次统一的环境部署和集成测试。这个集成测试或者叫回归测试每天晚上都做,都是在一个全新的环境中。如果某一天测试不通过,则会发邮件通知。

                9. 一个周期完毕,进行UAT测试。如果测试不通过,则会发邮件通知,开发人员要及时更正。

               10.UAT测试通过以后,准备上线到生产环境。建议采用灰度发布或蓝绿发布机制,分批次发布、切换流量。一般情况下,具有权限的管理人员通过自动化脚本进行部署。

            通过持续集成、持续交付这套完整的流程,层层保证质量,保证项目可以按时按质的完成,减少项目的实施风险。


      微信扫一扫,关注该公众号

      该系列文章已经在微信公众号发布,如果感兴趣,请关注。

       以后更多知识通过该微信公众号分享。


    展开全文
  • 如何画出一张合格的技术架构图?

    万次阅读 2019-04-11 09:23:57
    当我们想用一张或几张图来描述我们的系统时,是不是... 画出来的图到底是产品图功能图还是技术图又或是大杂烩? 图上的框框有点少是不是要找点儿框框加进来? 布局怎么画都不满意…… 如果有同样的困...

    当我们想用一张或几张图来描述我们的系统时,是不是经常遇到以下情况:

     

    • 对着画布无从下手、删了又来?

    • 如何用一张图描述我的系统,并且让产品、运营、开发都能看明白?

    • 画了一半的图还不清楚受众是谁?

    • 画出来的图到底是产品图功能图还是技术图又或是大杂烩?

    • 图上的框框有点少是不是要找点儿框框加进来?

    • 布局怎么画都不满意……

     

    如果有同样的困惑,本文将介绍一种画图的方法论,来让架构图更清晰。

     

    先厘清一些基础概念

     

    1、什么是架构?

     

    架构就是对系统中的实体以及实体之间的关系所进行的抽象描述,是一系列的决策。

     

    架构是结构和愿景。

     

    系统架构是概念的体现,是对物/信息的功能与形式元素之间的对应情况所做的分配,是对元素之间的关系以及元素同周边环境之间的关系所做的定义。

     

    做好架构是个复杂的任务,也是个很大的话题,本篇就不做深入了。有了架构之后,就需要让干系人理解、遵循相关决策。

     

    2、什么是架构图?

     

    系统架构图是为了抽象地表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界,以及软件系统的物理部署和软件系统的演进方向的整体视图。

     

    3、架构图的作用

     

    一图胜千言。要让干系人理解、遵循架构决策,就需要把架构信息传递出去。架构图就是一个很好的载体。那么,画架构图是为了:

     

    • 解决沟通障碍

    • 达成共识

    • 减少歧义

     

     

    4、架构图分类

     

    搜集了很多资料,分类有很多,有一种比较流行的是4+1视图,分别为场景视图、逻辑视图、物理视图、处理流程视图和开发视图。

     

    ★ 场景视图

     

    场景视图用于描述系统的参与者与功能用例间的关系,反映系统的最终需求和交互设计,通常由用例图表示。

     

     

    ★ 逻辑视图

     

    逻辑视图用于描述系统软件功能拆解后的组件关系,组件约束和边界,反映系统整体组成与系统如何构建的过程,通常由UML的组件图和类图来表示。

     

     

    ★ 物理视图

     

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

     

     

    ★ 处理流程视图 

     

    处理流程视图用于描述系统软件组件之间的通信时序,数据的输入输出,反映系统的功能流程与数据流程,通常由时序图和流程图表示。

     

    ★ 开发视图

     

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

     

     

    以上 5 种架构视图从不同角度表示一个软件系统的不同特征,组合到一起作为架构蓝图描述系统架构。

     

    怎样的架构图是好的架构图

     

    上面的分类是前人的经验总结,图也是从网上摘来的,那么这些图画的好不好呢?是不是我们要依葫芦画瓢去画这样一些图?

     

    先不去管这些图好不好,我们通过对这些图的分类以及作用,思考了一下,总结下来,我们认为,在画出一个好的架构图之前, 首先应该要明确其受众,再想清楚要给他们传递什么信息 ,所以,不要为了画一个物理视图去画物理视图,为了画一个逻辑视图去画逻辑视图,而应该根据受众的不同,传递的信息的不同,用图准确地表达出来,最后的图可能就是在这样一些分类里。那么,画出的图好不好的一个直接标准就是:受众有没有准确接收到想传递的信息。

     

    明确这两点之后,从受众角度来说,一个好的架构图是不需要解释的,它应该是自描述的,并且要具备一致性和足够的准确性,能够与代码相呼应。

     

    画架构图遇到的常见问题

     

    1、方框代表什么?

    为什么适用方框而不是圆形,它有什么特殊的含义吗?随意使用方框或者其它形状可能会引起混淆。

     

    2、虚线、实线什么意思?箭头什么意思?颜色什么意思?

     

    随意使用线条或者箭头可能会引起误会。

     

    3、运行时与编译时冲突?层级冲突?

     

     

    架构是一项复杂的工作,只使用单个图表来表示架构很容易造成莫名其妙的语义混乱。

     

    本文推荐的画图方法

     

     

    C4 模型使用容器(应用程序、数据存储、微服务等)、组件和代码来描述一个软件系统的静态结构。这几种图比较容易画,也给出了画图要点,但最关键的是,我们认为,它明确指出了每种图可能的受众以及意义。

     

    下面的案例来自C4官网,然后加上了一些我们的理解,来看看如何更好的表达软件架构

     

    1、语境图(System Context Diagram)

     

     

    这是一个想象的待建设的互联网银行系统,它使用外部的大型机银行系统存取客户账户、交易信息,通过外部电邮系统给客户发邮件。可以看到,非常简单、清晰,相信不需要解释,都看的明白,里面包含了需要建设的系统本身,系统的客户,和这个系统有交互的周边系统。

     

    ★ 用途

     

    这样一个简单的图,可以告诉我们,要构建的系统是什么;它的用户是谁,谁会用它,它要如何融入已有的IT环境。这个图的受众可以是开发团队的内部人员、外部的技术或非技术人员。即:

     

    • 构建的系统是什么

    • 谁会用它

    • 如何融入已有的IT环境

     

    ★ 怎么画

     

    中间是自己的系统,周围是用户和其它与之相互作用的系统。这个图的关键就是梳理清楚待建设系统的用户和高层次的依赖,梳理清楚了画下来只需要几分钟时间。

     

    2、容器图(Container Diagram)

     

    容器图是把语境图里待建设的系统做了一个展开。

     

     

    上图中,除了用户和外围系统,要建设的系统包括一个基于java\spring mvc的web应用提供系统的功能入口,基于xamarin架构的手机app提供手机端的功能入口,一个基于java的api应用提供服务,一个mysql数据库用于存储,各个应用之间的交互都在箭头线上写明了。

     

    看这张图的时候,不会去关注到图中是直角方框还是圆角方框,不会关注是实线箭头还是虚线箭头,甚至箭头的指向也没有引起太多注意。

     

    我们有许多的画图方式,都对框、线的含义做了定义,这就需要画图的人和看图的人都清晰的理解这些定义,才能读全图里的信息,而现实是,这往往是非常高的一个要求,所以,很多图只能看个大概的含义。

     

    ★ 用途

     

    这个图的受众可以是团队内部或外部的开发人员,也可以是运维人员。用途可以罗列为:

     

    • 展现了软件系统的整体形态

    • 体现了高层次的技术决策

    • 系统中的职责是如何分布的,容器间的是如何交互的

    • 告诉开发者在哪里写代码

     

    ★ 怎么画

     

    用一个框图来表示,内部可能包括名称、技术选择、职责,以及这些框图之间的交互,如果涉及外部系统,最好明确边界。

     

    3、组件图(Component Diagram)

     

     

    组件图是把某个容器进行展开,描述其内部的模块。

     

    ★ 用途

     

    这个图主要是给内部开发人员看的,怎么去做代码的组织和构建。其用途有:

     

    • 描述了系统由哪些组件/服务组成

    • 厘清了组件之间的关系和依赖

    • 为软件开发如何分解交付提供了框架

     

    4、类图(Code/Class Diagram)

     

    这个图很显然是给技术人员看的,比较常见,就不详细介绍了。

     

    案例分享

     

    下面是内部的一个实时数据工具的架构图。作为一个应该自描述的架构图,这里不多做解释了。如果有看不明白的,那肯定是还画的不够好。

     

     

     

     

     

     

     

     

    画好架构图可能有许多方法论,本篇主要介绍了C4这种方法,C4的理论也是不断进化的。但不论是哪种画图方法论,我们回到画图初衷,更好的交流,我们在画的过程中不必被条条框框所限制。简而言之,画之前想好:画图给谁看,看什么,怎么样不解释就看懂。

     

    作者简介:三画,阿里巴巴技术专家,梓敬、鹏升和余乐对此文亦有贡献。三画曾多年从事工作流引擎研发工作,现专注于高并发移动互联网应用的架构和开发,和本文贡献者均来自阿里巴巴零售通部门。目前零售通大量招Java开发,欢迎有志之士投简历到 lst-wireless@alibaba-inc.com,和我们一起共建智能分销网络,让百万小店拥抱DT时代。

     

    参考资料:

    C4官网:https://c4model.com/

    为什么需要软件架构图:

    https://www.infoq.cn/article/GhprrUlOYyOqS8*FR1pH

    书籍:《程序员必读之软件架构》

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

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

    千次阅读 2019-03-21 11:28:56
    《大型网站技术架构:核心原理与案例分析》笔记 高可用性 什么是可用性? 可用性(Availablility)是指服务可被有效访问的特性,不是指有用性(Usability)。 能够保证服务永远可用吗? 保证服务永远可用几乎是一件...
  • 今日头条技术架构分析

    万次阅读 2018-11-25 17:13:43
    ​ ​ 今日头条创立于2012年3月,到目前仅4年时间。从十几个工程师开始研发,到上百人,再到200余人。产品线由内涵段子,到今日头条,今日特卖,今日电影等产品线。 一、产品背景 ​ ​ 今日头条是为用户提供...
  • 技术架构

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

    万次阅读 2016-03-09 21:02:18
    淘宝网技术架构介绍 学习目标:  1.了解淘宝架构的需求;  2.了解淘宝技术的演变;  3.了解架构的一些基本准则。 淘宝相关的一些数据 淘宝架构的版本演变  V1.0架构...
  • 架构可细分为业务架构、应用架构、技术架构, 业务架构是战略,应用架构是战术,技术架构是装备。 应用架构承上启下: 1、一方面承接业务架构的落地, 2、一方面影响技术选型  应用架构类型:单体式...
  • 系统架构:指的完整系统的组成架构,例如系统分成几个部分?服务平台、管理门户、终端门户、ATM门户、外部系统以及接口、支撑系统等,将这些系统进行...技术架构:从技术层面描述,主要是分层模型,例如持久层、数据
  • java 各种架构图汇总

    万次阅读 多人点赞 2019-07-09 22:09:34
    JMS 技术架构 7. JMX 技术架构 Spring 架构 9. Hibernate 架构 ibatis 架构 Struts2 架构 Struts1 架构 JBPM EJB 技术架构   Portal J2EE S...
  • 一张图告诉你什么是系统架构

    万次阅读 2018-01-09 10:11:31
    这张图从架构师的综合能力、岗位认识、岗位职责等方面,清楚的画出了作为一个架构的基本准则。人人都想成为架构师,可作为架构你达到了上面的要求了吗? 系统架构师是个神奇的岗位。为什么这么说,在一个人数不多的...
  • 一、系统架构 1、描述 2、示例图 二、软件架构 1、描述 2、示例图 三、总体架构 1、描述 2、示例图 四、业务架构 ...七、技术架构 1、描述 2、示例图 八、物理架
  • 用VISIO画的分层架构设计图

    万次阅读 2008-11-14 17:28:00
  • 系统架构设计方法论——TOGAF

    万次阅读 2017-08-27 15:49:35
    1、ADM的架构开发阶段 ADM方法是由一组按照架构领域的架构开发顺序而排列成一个环的多个阶段所构成。通过这些开发阶段的工作,设计师可以确认是否已经对复杂的业务需求进行了足够全面的讨论。TOGAF中最为著名的一个...
  • 大数据技术框架图解

    万次阅读 2018-10-31 15:18:30
    大数据技术框架见附件: 数据处理:
  • 大数据架构师是做什么的?

    万次阅读 2018-04-03 15:41:11
    架构师按照专注领域不同,可分为企业架构师、基础结构架构师、特定技术架构和解决方案架构师等,专职架构师往往偏向基础结构架构师和特定技术架构师,专职架构师不负责具体的业务系统,而又对所有的系统负责,很少...
  • 服务器技术架构

    万次阅读 多人点赞 2018-03-18 21:26:54
    一、服务器技术架构的三大发展趋势一般而言,客户需求决定了服务器的发展方向,从服务器的技术架构来看,目前整个服务器的技术架构的发展有三个大趋势:纵向扩展架构、横向扩展架构、超融合架构。 1、纵向架构...
1 2 3 4 5 ... 20
收藏数 914,643
精华内容 365,857
关键字:

技术架构