软件设计与体系结构 课件 第6-10章 成为架构师-微服务架构

7-成为架构师1概述软件系统是对物理世界的抽象，离开物理世界越远，抽象程度越高。抽象的意思是在纷繁复杂、有千丝万缕联系的事物之间，找到其共性部分。码代码和做架构是两种不同的抽象级别。普通程程序员通常用代码思考，负责一个系统中的几个小模块，所以思维常常局限在低层（low-level）、战术（tactic）的层面，考虑的基本上大多是某个功能、某个模块实现的具体细节与技巧。这是应该而且正常的，是团队合理分工的结果。Theunexaminedlifeisnotworthliving.（未经审视的人生不值得过。）——苏格拉底2概述架构师，顾名思义，要负责整个系统的架构，尤其是涉及到一个系统（或子系统）全局的整体设计。所以往往需要高层、上层（high-level）的战略（strategic）层面的思考，这样就必然需要架构师经常进行建模（Modeling），对代码、模块、子系统和系统中的各种静态结构、关系和动态行为、交互等等进行抽象。所以，在架构师的日常工作中，经常看到各种各样的图表、图形符号和模型，是很正常的。可以说，不会建模，不习惯于用模型思考的程序员，是很难成为一名称职的软件架构师。3概述架构师是一个既能掌控整体又能洞悉局部瓶颈，并依据具体的业务场景给出解决方案的团队领导型人物。看似完美的“人格模型”背后，是艰辛的探索。架构师在广大码农中的占比大概平均不到10%。而架构师也可以分为初级、中级、高级三档，江湖上真正高水平的软件架构师就更少了。有一些技术人员成长很快，能够迅速成为团队的骨干，也有一些技术人员总是在原地踏步，工作十年和工作一年的区别并不大。渐渐地，发现这些优秀的技术人员都有一些共同的特质和素养，从而帮助他们不断进步，脱颖而出。4Agenda架构师职责架构师需要的技能架构师的分类架构师日常工作为什么要向架构师转型？如何向架构师转型如何打造属于自己的技术体系5架构师职责软件架构师是指那些制定高级设计决策，并确定技术标准（包括软件编程标准、工具和平台）的软件专家。架构师，是一个既需要掌控整体又需要洞悉局部瓶颈，并依据具体的业务场景给出解决方案的团队领导型人物。架构师不是一个人，他需要建立高效的体系，带领团队去攻城掠地，在规定的时间内完成项目。这之中的首席专家就是总架构师。架构师的职责有：❶理解并解析需求；❷创建有用的模型；❸确认、细化并扩展模型；❹管理架构。6架构师职责软件架构师和产品经理之间的关系可以从这张图中看出。产品是“桥”，连接了两端，分别是用户需求和先进的技术。用户需求的变化非常缓慢，那么为什么产品会产生迭代？这是因为技术在迭代。本质上讲，产品迭代是技术迭代导致的、对需求满足方式的一种变化，所以产品实际上是一种需求满足的方式。7架构师职责从这个意义上讲，架构师更多是从技术方案的角度看产品，而产品经理更多是从用户需求来看，但二者一定会碰头，只要能力提升到角色所期望的样子，越厉害就越具备两侧的能力。产品经理和架构师是一体两面，本质上对人的能力、诉求是相通的。产品经理在做产品架构，架构师在做技术架构，但最终目的一样。8从产品和需求视角看架构师如果展开讲解产品定义过程，首先需要进行需求梳理，关心用户反馈。但是，很多用户反馈并不代表其根本性需求。有很多用户反馈需求的时候，往往已经带着他自己给出的解决方案。这种需求反馈已经属于二次加工的需求，而非原始需求。这个时候我们要多问多推敲，把它还原到不带任何技术实现假设的根源需求。9从产品和需求视角看架构师10从产品和需求视角看架构师第一、根源需求可能会有非常非常多的技术方案可以满足它。上面示意图中的小圆点是一个个用户反馈的需求。在用户提这些需求的时候，往往可能会带着他熟悉的技术方案的烙印。产品都是通过提供相应的技术方案、在满足用户的根源诉求，但技术一直在迭代进步，从而导致原有的解决方案过时落后，这种情况下需要新的解决方案出现。如果对用户反馈的需求全部满足，产品就会变得十分庞大，编程一个四不像的东西。11从产品和需求视角看架构师其次，在这个过程中，有些用户需求是稳定的，有些是变化的。举例来说，计算机系统结构从计算机诞生之后到现在没变过，但电子设备的形态发生了很大变化，从最早的大型机，到个人电脑，到笔记本，到手机，再到手表，形态变化剧烈。但为什么计算机系统结构能够适应需求而不用改变架构，这其实是非常值得思考的事情，其根源就是对变化点的抽象，找到系统需求的变化点，预见变化并做对应的开放式设计。本质上讲，架构师关心产品的核心根源就是预测变化。12从产品和需求视角看架构师最后，理清产品边界。同样以计算机为例，经过多轮迭代，多样化外设（键盘等）变化较大，但CPU、内存演进较小，所以在变化点上做相应的开放式设计是必要的。同样的，需要与合作伙伴做边界设定，把变化开放出去让合作伙伴做，只有这样的产品才能达到较好效果。从产品和解决方案角度来看，产品往往需要适应很多行业，但这个过程会让产品变得非常庞大。因此，产品应该为行业解决方案提供能力，行业解决方案优先选择合作伙伴做，以更加开放的心态看待这件事情，避免把特定行业方案视作产品的一部分。13从产品和需求视角看架构师梳理需求中比较关键的点是市场策略，需要解决的需求有非常多现成的方案，但哪些方案是主流的，哪些是最关键的都需要思考。虽然不能放大产品需求覆盖面，但也需要为某些关心既有市场的玩家做桥梁，这些桥梁也是产品的功能点。因此，关键市场可能会把既有玩家的能力适配到产品上作为很重要的功能，但是大部分市场主流方案我们还是提供“桥”，而不是自己解决掉。14从技术视角看架构师以上是从产品和需求维度看架构师，从技术视角看，架构师很重要的能力是具备技术的全局视角：所谓的技术全貌是指从底到上的核心骨架，比如最底下的硬件结构、操作系统、编程语言，甚至浏览器等，只有掌握每一层的核心思想，才能在架构设计中没有技术盲点。从培养架构师的角度来看，为什么真正意义上的架构师比较难找？这是因为需要构建两个层次的能力：15从技术视角看架构师1、懂用户、懂市场，有一定市场洞察能力。作为技术人员，可能会不自觉、甚至不愿意和用户打交道，更希望坐在家里安静码代码。但是，作为架构师，不和用户打交道，成长会比较受限，不接触用户就无法理解用户需求，亲自和用户打交道倾听来的需求和探讨完全不一样。因此，架构师要尊重用户反馈，并学会思考需求分析和推演，这比技术能力更重要。架构的第一步就是需求分析，如果需求分析没做好，后续自然没办法做得很极致。16从技术视角看架构师2、建立技术上的全局视角。以上两点是架构师最核心的两个能力。最后，结构基本是相互交织的两条线索：（1）信息世界的构建过程，从底层硬件到操作系统逐层递进，还原信息世界的构建历程，主要关注宏观结构及需求变化，每一层都经历了哪些变化；（2）架构方法论。如果我们纯讲架构方法论，容易过度抽象，比如什么开闭原则。我们要结合信息世界的构建过程讲，它本身就是最宏大的架构实践案例。17得到架构师的主要职责1、确认需求架构师要懂得用户需求，理解用户真正想要什么，这使得架构师必须要和分析人员不断沟通，反复确认需求规格说明书，以此来保证他精准清楚用户需求。项目经理刘先生在受访时说：「架构师会与很多人沟通，例如开发人员，例如我们项目经理，有时甚至是用户本身。架构设计的目的很明确，目的是什么呢？挖掘用户需求。」18得到架构师的主要职责2、系统分解。在架构师认可需求规格说明书后，架构师已明确用户需求是是什么，这时候便看架构师的分解能力了。通过100offer入职的全栈技术架构师周先生从「纵向分解」和「横向分解」和我们说明了系统分解是什么——一般分为纵向分解和横向分解，纵向分解是将整个系统分层，从而将整体系统分解成下一级的子系统与组件。横向分解是在系统分解成不同的逻辑层或服务后，对逻辑层进行分块，确定层与层之间的关系。19得到架构师的主要职责3、技术选型。在系统分解后，架构师会最终形成软件整体架构，接下来，架构师的职责是技术选型。「前端到底用瘦客户端还是富客户端呢？数据库是用MySQL还是MSSQL又或是Oracle呢？」架构师张先生在接受采访时说，「在了解用户需求后，分解完系统后，技术选型是非常重要的环节，提出各个方向，我再进行评估。不过，很多人都以为架构师是有决定权的，其实不是，架构师没有拍版的权力，决定由项目经理来做。」架构师在技术选型阶段会提供参考信息给项目经理，项目经理再从预算、进度、人力、资源等各方面情况来权衡，最终确认。20得到架构师的主要职责4、制定技术规格说明。如前文调查显示，架构师在项目开发过程中是「灵魂人物」，并且要具备协调组织能力和懂得人员分工。在制定技术规格说明阶段，架构师要协调起所有的开发人员，架构师通常会用技术规格说明书与开发人员保持沟通：让开发人员能从各个视角去观测、理解他们负责的模块或者子系统，确保开发人员能够按照架构意图实现各项功能。21Agenda架构师职责架构师需要的技能架构师的分类架构师日常工作为什么要向架构师转型？如何向架构师转型如何打造属于自己的技术体系22架构师需要的技能（1）趟过语言之河：软件架构师不用精通某种编程语言，但是一定要对各种主流语言十分熟悉，C++、Java、Python、C#、JavaScript(TS/ES)、Ruby、Scala、Perl、Dart......因为当今任何一款上规模的软件，都是多种语言的组合。于是有人说啦，我精通Java，要带领团队用Java搞定一切！这不是不可以，但是：当用Python搞在实现同样性能功能的同时，还能大幅度降低研发成本而你仍坚持用Java时，那你就不是一个合格的架构师。23架构师需要的技能（2）熟悉IT基础环境：网络、服务器硬设、存储设备、操作系统、文件存储系统、虚拟机......你不可能在不了解这些基础环境的情况下就跑去搭架构。（3）精通数据库：除了精通传统数据库及分布式数据库理论，你还得对Oracle、MySQL、PostgresSQL、OceanBase、TiDB、Cassandra、HBase、MongoDB、Redis、Neo4j......等数据库系统十分熟悉，鉴于人的精力有限，各类数据库（关系型、NoSQL、KV）你只需精通一个系统就够用了。24架构师需要的技能（4）通晓主流框架和中间件：不同的语言，对应不同的基础框架，譬如C#对.Net，Java对Spring，Python对应Django/Flask、Dart对Flutter，软件研发实施的过程就是往这些框架里头塞东西的过程。除了基础框架外，为了实现不同的功能、达到不同的目的，我们还会选用诸如Spark、TensorFlow、OpenCV、Hyperledger、ElasticSearch、网飞微服务套件、RabbitMQ、Kafka、Zookeeper、SSH、SSM、Docker等各种各样的框架或中间件。你至少得知道什么时候选哪一个。25架构师需要的技能（6）别忘了设计模式：二十多种设计模式，都是学院派或者前辈们总结出来的设计经验。尽管经常用到的翻来覆去就那么几种（什么单例、共享、工厂、组合），但是咱们还得把里头的精髓给它掏出来，以便灵活运用。26架构师需要的技能（7）玩转工程化。即便上面的技术你全都掌握了，工程化做不好，还是白搭。工程化的核心目标是用最省钱的方式实现能赚钱的软件。一款软件，做出来是给人用的，有人用了才能赚钱，而不是功能和技术的简单堆砌，技术大牛们在工程化时重技术堆砌而忽略成本是经常见到的事情。软件工程化是一个系统工程，并不是说你精通瀑布模型、软件成熟度模型、XP、Scrum、DevOps就能搞得定的，你还得学会筛选过滤需求、学会软件设计（当然，一般都会有产品经理配合你，或者会有产品经理压着你）、学会技术选型、学会任务切分及分配、学会用人管人、学会控制成本、学会跟领导打交道......27Agenda架构师职责架构师需要的技能架构师的分类架构师日常工作为什么要向架构师转型？如何向架构师转型如何打造属于自己的技术体系28架构师的分类从业界来看对于架构师有不同的区分：1）企业架构师：专注于企业总体IT架构的设计。2）IT架构师-软件产品架构师：专注于软件产品的研发。3）IT架构师-应用架构师：专注于结合企业需求，定制化IT解决方案;大部分需要交付的工作包括总体架构、应用架构、数据架构，甚至部署架构。4）IT架构师-技术架构师：专注于基础设施，某种软硬件体系，甚至云平台，提交：产品建议、产品选型、部署架构、网络方案，甚至数据中心建设方案等。29架构师的分类或者，按照不同的层级，架构主要可以抽象成以下几个「层级」。1）应用级：最低层级的架构。只关注单一的应用。层级低，但是很详细。这方面的交流一般是在一个开发团队内展开；2）解决方案级：架构的中间层。关注一或多个满足业务需求的应用（也就是商业方案）。这之中有些设计是高层次的，但大部分还是低层次的设计。这种层级架构的交流就开始涉及多个团队了；3）企业级：架构的最高层级。关注多个方案。这种架构的设计层次高且抽象，因此也需要方案级和应用级的架构师对此进行细化。这种层次的架构就需要多个组织进行沟通了。30Agenda架构师职责架构师需要的技能架构师的分类架构师日常工作为什么要向架构师转型？如何向架构师转型如何打造属于自己的技术体系31架构师日常工作定义和确定所需的开发技术与平台；定义开发标准，如编程标准、工具、审核流程、测试方法等；对确定和理解业务需求提供支持；设计系统并根据需求做出决策；对架构定义、设计和决策进行讨论记录；检查并审核架构与代码，比如检查前期确定的模式与编程标准是否被正确实施；与其他部门和架构师合作；对开发人员的引导及咨询；将高级设计细化，并转化为较低级的设计。32Agenda架构师职责架构师需要的技能架构师的分类架构师日常工作为什么要向架构师转型？如何向架构师转型如何打造属于自己的技术体系33为什么要向架构师转型？无论对于传统行业还是互联网行业，开发具有功能强大且用户体验好的移动端应用已经成为众多软件从业人员的目标和要求。然而，分析和设计一个软件系统以及管理其研发过程并不是每一个软件行业从业人员都能做的事情，需要具备专业的知识领域、丰富的实践经验以及良好的个人综合能力，我们把具备以上能力的人才称之为软件架构师。中国目前每年有几十万的软件开发人才缺口，其中对具备系统架构设计和实现能力的人才更是趋之若鹜。对于一名软件开发人员而言，成为一名合格乃至优秀的架构师是自身奋斗的一个方向。目前很多公司尤其是大型公司程序员并不缺，缺的是架构师。34为什么要向架构师转型？同时，对于一名具备多年行业从业经验的开发人员，如果目前还处在普通的开发人员序列，还没有具备相应的意识形态和专业能力去从事系统架构设计和实现相关工作的话，势必导致技术与年龄不相匹配，也就会出现职场上经常谈论的所谓“30岁危机”。所以，从这个角度讲，成为一名架构师事实上也是自身发展所不得不面临的一个瓶颈。如何打破这个瓶颈，如何从普通的程序员转型成为一名架构师，对于广大开发人员而言都可能是一个值得思考的问题。当然，对于从事技术开发的人员而言，技术变化日行月异，一个人的能力很大程度上体现为一种学习能力。如何实现自我提升，如何看到目前还没有看到的技术层次，也是个人发展道路上不可回避的一个话题。35从周围的两君说起杭州有家公司叫阿里巴巴，一些朋友去阿里巴巴面试，有些成功入职，有些虽然最终入职但过程比较艰难，而有些则一直没有找到机会。这里举两个例子与各位分享。张A：每一面都顺利通过，一次性走完所有流程，历时约1个半月入职阿里闲鱼。阿里闲鱼是阿里旗下一个二手商品的交易平台，1个半月的面试时间在入职阿里的过程中已经算是比较快的流程，需要做到每一面都一次通过。这里简单介绍一下阿里的面试流程，正常情况下是4轮面试，有些部门在同一轮面试中会对候选人进行多次面试，如果一次不行还会安排不同的面试官再面一次。而每次面试都需要协调面试人员，所以整体流程通常都会比较长。36从周围的两君说起李B：一共面试11个岗位，其中一面失败5次，二面失败6次，三面失败2次。从今年上半年开始，历时半年仍未入职。目前已放弃，准备做一定积累之后再进行尝试。事实上，这两位的年龄、工作履历以及技术能力相差无几，那为什么面试同一家公司结果会完全不同呢？通过对这两位同事的面试经历进行分析，我们能够得出一个结论，即知识体系的重要性。37从周围的两君说起再举一个例子王C：10年以上开发经验，工作能力和态度都没有问题，但一直都是从事偏向业务的开发工作，随着年龄的逐渐偏大，目前已经明显遇到了职业生涯发展瓶颈。就与王C的对比，张A从薪资上目前是王C的两倍，并且对系统架构和技术管理体系都非常了解，成功担任过大型企业中的系统分析架构师与技术总监职务，可以说在一定程度上已经突破了目前所面临的发展瓶颈。针对王C的案例而言，我们同样得出另外一个重要的结论，即转型思维的重要性。程序员向架构师转型应该具备相应的转型模型？38Agenda架构师职责架构师需要的技能架构师的分类架构师日常工作为什么要向架构师转型？如何向架构师转型如何打造属于自己的技术体系39如何向架构师转型哪些特质适合往架构方向发展？（1）对技术有足够的热情和好奇心。这些年技术的更新换代非常快，如果你对技术缺乏热情或好奇心，那你就很容易被时代所抛弃，滞留在曾经最擅长最熟悉的技术栈上。只有保持对新生事物的好奇心，愿意拥抱变化，才能够不断刷新自己的技术栈，从而积累丰富的经验，拓展自己的认知。40如何向架构师转型哪些特质适合往架构方向发展？（2）善于跳出纷繁、抽象总结方法论。在这个充满变幻的环境中，我们很容易陷入细节不能自拔，被各种业务问题套住不能脱身，意识不到跳出这些变化来总结共性的解决方案，从更高的维度来解决问题。如果你平时喜欢流程化、层次化、系统化地思考问题，那你就具备了做架构的基本条件。41如何向架构师转型哪些特质适合往架构方向发展？（3）乐于与人沟通交流，兴趣爱好宽泛。架构师需要跟各种干系人角色沟通交流，如果你本身不太喜欢跟人打交道，那么架构相关的工作对你来说就比较有挑战。相对于技术专家的精深，架构更偏广博，兴趣爱好宽泛就有助于你拓宽自己的技术面和人脉圈，从而为做好架构积累内外资源。42如何向架构师转型哪些特质适合往架构方向发展？如果你对某个技术领域特别喜欢，性格相对内向，兴趣爱好单一，那就可以往专精方向发展，成为这个领域的技术专家。如果你性格外向，兴趣爱好宽泛，那就可以往广博方向发展，成为跨不同领域的架构专家。不管往哪个方向发展，最根本的就是充分发挥自身优势，不断提高自己的不可替代性，站上更高更大的舞台，做更大更有价值的事情。43如何向架构师转型-三步走我们每个人都会遇到转型升级这个命题，要么是被动的，要么是主动的。什么是被动呢？就是职业发展遭遇瓶颈或天花板，薪酬待遇上涨乏力，相对于年轻人在市场上的竞争力降低，甚至遭遇末尾淘汰或裁员等等，这是任何人都不愿意看到的，最好还是提前规划主动转型。当然，任何人都不能脱离现实生存的约束，在完成转型升级前，我们还需要依靠眼下最擅长的技能谋生。因此，我们不要幻想自己在某天就突然可以胜任架构师的工作了，最靠谱的还是三步走策略。44如何向架构师转型-三步走第一步，在开发岗上积累丰富的开发和设计经验，熟悉各种中间件产品。第二步，在开发岗上学习架构相关的理论和方法，寻找机会做架构设计，提升架构师所需的软技能。第三步，晋升或跳槽到真正的架构岗，正式以架构师角色开展工作，培育后续转型升级的新技能树。45如何向架构师转型-三步走上述三步当中，第二步比较难，在做好本职工作的同时，主动跳出舒适区，不断扩大自己的技术视野。因为很多人会被公司的业务和技术环境牵着走。例如，公司当前的业务规模决定了技术上不需要分布式技术，很少有人会思考业务规模大了之后如何利用分布式技术来化解问题。如果你准备往架构师方向发展，除了寻找更大规模的业务外，那你要养成跳出当前层级和环境来思考的习惯。46如何向架构师转型-三步走例如你只用了关系型数据库，有没有想过当数据到达TB数量级时如何快速检索与保存呢？技术能力的突破依赖：业务场景的需求和自身刻意的规划学习，二者缺一不可。但前者是机会，往往不是自己能完全把控的，如果在工作中没有实践场景，最好的办法就是系统的学习与梳理，待机会来临时才能一展身手。47如何向架构师转型-转型规划（1）数据结构和算法——基本的编程原理对软件架构师来说应该不成问题，包括数组、队列、栈、链表、不同类型的树、图等数据结构，软件架构师不仅应该熟悉，而且应该能够识别出在什么时候应该使用哪个数据结构。优秀的软件架构师应该知道不同的算法，如搜索、排序、递归、动态规划等。在日常生活中，没有架构师会从头开始编写“合并排序”算法，或者发明新的数据结构。《算法导论》是一本全方位介绍算法和数据结构的经典作品。48如何向架构师转型-转型规划（2）技术栈：无论是后端还是前端，软件架构师必须非常了解当前使用的技术栈。学习特定编程语言的语法是最简单的方法，但需要时间积累经验。不同的库和框架也是值得了解的宝贵资产。（3）简洁的编码：让软件系统工作并不是软件架构师的最终目标。每次评审代码时，他/她首先想到的问题是：我能使这段代码更高效吗？我能让代码占用更少内存吗？简洁的代码标准是否被正确应用？我可以使用不同的OOP技术吗?《代码整洁之道》无疑可以帮助我们提高重构技能。49如何向架构师转型-转型规划（4）OOP：面向对象编程帮助我们可以构建更灵活、高效、可读性高的软件系统。有经验的软件架构师会经常使用这些技术(如果技术堆栈合适……)。（5）软件设计模式：说到面向对象，不应该忘记不同的设计模式的重要性，它们首先是由GoF收集和引入的。了解这些设计模式肯定会帮助我们更好的利用软件系统的面向对象设计。从R.C.Martins的著作《架构整洁之道》中可以学到设计原则。（6）S.O.L.I.D.原则：这一组件原则是软件组件设计中需要考虑的基本技术。有经验的软件架构师如果掌握了这些原则，可以很快识别出代码中的违规行为。50如何向架构师转型-转型规划（7）高内聚/低耦合原则——REP重用发布等价原则、CRP共同重用原则、ADP无环依赖原则等对于软件架构师来说非常重要，尤其是在构建、整合/解耦插件时，这些技术可以处理更高级的设计。（8）系统设计：有很多软件体系架构模式，如:主从、客户端-服务器、微服务、MVC、单向体系架构等，需要根据不同的前后端项目做出选择。当然不太可能有人能够掌握所有这些模式，但是根据项目的不同，软件架构师应该精通底层设计，领域驱动设计可以作为最基本的出发点。51如何向架构师转型-转型规划（9）文档——这是软件架构师日常工作中的重要环节。绘制不同的UML图，ARC42文档是这个职位不可避免的工作。这方面有很多工具，如：draw.io——简单易用的免费工具；PlantUML——提供Eclipse、IntelliJ等IDE插件，可以通过脚本绘图，非常有用，也是我最喜欢的工具；yEd——很方便的工具，可作为桌面应用程序运行。52Agenda架构师职责架构师需要的技能架构师的分类架构师日常工作为什么要向架构师转型？如何向架构师转型如何打造属于自己的技术体系53如何打造属于自己的技术体系技术的成长是靠一步一步走出来的，不可能一口吃个胖子。既然上面聊了程序员在这条职业道路上应该具备的一些技能和素质。那这里就再补充一下如何去提高这些技能，如何去一步一步走出自己的技术体系。54如何打造属于自己的技术体系（1）点：我们可以把学到的任何一个知识/技能都当做一个「点」。比如我们刚接触计算机编程的时候学习了数据结构、后来又学习了Java基础，然后在工作中又学习了框架Spring，然后根据项目需要又学习了Linux、学习了Hadoop、学习了JavaScript，等等。我们在初级阶段的时候，是在不断的学习各种知识技能，这些就像是天上的星星一样，一个一个的零散的知识点，它是不成体系的，我们需要用到什么就去学习什么。这些不成体系的知识点帮助我们完成了工作，但是它们又很容易被忘记，且一般都不够深入。55如何打造属于自己的技术体系（2）线：随着我们学到的「点」越来越多之后，就会发现里面有些「点」是有关联的，甚至是触类旁通的。那么这些「点」在我们的脑海中就可以慢慢的形成「线」被串起来。它是一个随着累积之后，自然而然的过程，当然也需要我们不断的去总结知识。而有一部分知识点可能随着技术的变迁，没有合适的「线」去串联，也就慢慢的被我们所放弃。「线」是由「点」汇聚而成。因此要想知识能够形成「线」，我们除了不断学习以外，还需要不断的找出知识技能的共性和规律。56如何打造属于自己的技术体系（3）面：「面」又是由「线」交织而成。这个时候我们对技能的认知就从一维上升到了二维。这个「面」就像一张技能地图一样，所有的知识技能都能在这张地图里面找到位置和关系。我们再学习新的知识的时候，也只不过是往这张地图里面添加一些锚点，每次添加，都会让这个知识更为牢固和深刻。这就是我们追求的每个人自己的技术体系图了。57架构师的学习模型转型的过程本质上还是一个不断学习和进步的过程。对于正在向架构师转型的开发人员而言，处于初始阶段的同学有转型的想法和思路，但是在纷繁复杂的技术知识体系和各种层出不穷的工具框架面前就显的无从下手。而有些同学已经跨越了初级阶段，并按照自己的方法正在系统的梳理各种架构师所需的技能，但很多时候会发现效果不是很好，自身提升的速度比较慢。学习模型的作用就在于为这两类人提供一个简单的方法确保能够快速成长。58架构师的学习模型第一阶段第一阶段的主要工作是找一两个核心框架和技术体系进行深入分析并抽象出其中的技术理论。所谓理论指导实践，架构师一定要从纷繁复杂的技术知识体系和各种层出不穷的工具框架中抓住其背后的原理，然后做到用自己的语言对这些原理进行阐述。事实上，现在很多大型公司的架构师面试风格上就是偏向于考察面试者的原理分析能力和表达能力，这点我们在后续中会再结合架构师面试的技巧以及部分面试题做进一步展开。59架构师的学习模型第二阶段在第二阶段，架构师需要广泛了解其它框架和技术体系，看能否把在第一阶段中自己抽象出来的技术理论用来剖析这些框架，如果不能，找各种资料继续第一阶段。60架构师的学习模型-循环从上面的两个阶段我们可以看出学习模型是一个循环模型，就自身经历而言，一般人都需要经历过3~5个循环之后才能对架构设计这一领域有比较深入的理解。对于初始阶段，可以找类似Mybatis、Spring等相对比较独立的核心框架入手，然后逐步过渡到向Dubbo（Dubbo3.0支持云原生）、Zookeeper（Nacos）

等综合型框架。而对于那些已经完成初始阶段的同学而言，需要在不同的循环中针对不同的知识体系做相应的规划，可以针对分布式、微服务等主题进行专门的学习和训练。61关于架构师的几个常见的话题62关于架构师的几个常见的话题在明确了架构设计的基本概念之后，我们将要进一步讨论架构师角色。围绕架构师角色存在如下几个常见的话题。架构设计到底是一种技术活还是业务活？架构师到底要做哪些工作？架构师到底是不是一个技术管理岗？架构师有哪些类型？架构师应该具备哪些技能和职责？如同前面给出的关于架构设计方面的定义，不同的公司、不同的行业和不同的时期对这些问题也是见仁见智，我们只是基于最普遍的场景给出适合我们自身的答案。63Q1：架构设计到底是一种技术活还是业务活？在很多技术人员的眼中，架构设计可能就只是一种技术性的工作，很多公司在招聘架构师的时候也过多的关注了候选人的技术能力。事实上，在大型软件系统中，架构设计被认为是从问题领域到解决方案的一种桥梁（见下图），从图中我们可以看到架构设计活动与代表问题域的需求分析活动，和代表解决域的软件开发活动都有直接的交集，连接着两个软件开发的核心领域。64Q1：架构设计到底是一种技术活还是业务活？架构师是架构设计的执行者，架构设计的桥梁作用给架构师带来了挑战，意味着架构师需要同时具备处理两个核心领域的能力，即架构师需要能够从问题领域出发推导出满足业务需求的架构体系，同时又能够从实现方法入手，设计出能够满足业务架构需求的技术架构体系，最终实现业务架构和技术架构的统一。65Q2：架构师到底要做哪些工作？架构师是负责设计、记录和领导能够满足所有干系人需求的系统构建过程的人。通常，这个角色需要完成以下几项活动。❶识别干系人并让他们参与进来干系人是业务需求的源头，识别正确的干系人能够确保业务需求的正确性，让干系人参与能够确保业务需求的实时性和有效控制需求变更。❷理解和记录系统功能和非功能相关的关注点通过需求分析，架构师梳理并抽象系统的各项功能性和非功能性需求，并对这些需求进行系统建模。66Q2：架构师到底要做哪些工作？架构师是负责设计、记录和领导能够满足所有干系人需求的系统构建过程的人。通常，这个角色需要完成以下几项活动。❸创建并拥有应对这些关注点的架构定义对功能性和非功能性需求，从扩展性（Extensibility）、性能（Performance）、可用性（Availability）、安全性（Security）、伸缩性（Scalability）等架构设计的基本维度出发定义架构。❹在把架构实现为具体系统的过程中起主要作用推动架构设计活动按照项目和产品计划有序进行，参与需求、设计评审等各种技术评审过程，并管理系统设计和开发团队的日常工作。67Q2：架构师到底要做哪些工作？下图体现了传统瀑布（Waterfall）模型下的系统开发生命周期与架构师参与情况，从图中可以看出在由需求分析和系统建模所构成的系统初始阶段，和由服务集成和产品接受所构成的最后交付阶段，架构师会较多的参与到系统建设过程中去，具体参与程度取决于系统本身的特征以及生命周期模型。68Q2：架构师到底要做哪些工作？对于类似Scrum的敏捷开发模型，如果把一个个迭代看成是小型的Water-Scrum-Fall模型的话，架构师参与程度实际上也与上图所示的结果相类似，即重点参与迭代计划阶段和迭代演示回顾阶段。69Q3：架构师到底是不是一个技术管理岗？很多时候，我们也把架构师归为是一种技术管理者角色。技术管理者的工作包括设计行业与解决方案、推进业务结构与产品化、架构设计和技术创新、开展软件项目管理和研发过程体系建设等。视环境的不同，架构师也会在这些工作中发挥一定的推动作用。但就一个完整的产品开发生命周期而言，技术管理活动也具有其时效性，这种时效性相较于系统架构设计和实现等技术专业类活动而言，还具有较大的灵活性。我们可以理解为系统开发生命周期是整个完整软件产品生命周期的一部分，如下图所示。70Q3：架构师到底是不是一个技术管理岗？在系统开发工作开展之前，技术管理者需要进行行业分析、技术解决方案的设计以及产品开发策略的规划，同时针对行业特点也可能会从事部分的技术预测工作。而在系统开发工作结束之后，随着产品和运营工作的开展，技术管理者也要深入其中从组织战略的角度出发对技术提出进一步的规划方案和创新措施。71十大技能72/72十大技能1.设计我们想要的是一个可维护、可靠、可适应、安全、可测试、可扩展、可用的系统。而实现所有这些要求的方法就是有一个好的架构设计方法。你需要自己去尝试并感受这项技术的喜与悲。架构师不仅要有广博的知识面，还要在一些领域有深厚的积累。重点不在于掌握所有的技术栈，而是对你所在领域最重要的技术有坚实的理解。73/72十大技能2.决策架构师需要制定决策，指引项目甚至整个公司的正确方向。分清主次：不要在不重要的决策和工作上浪费时间，要学会分清主次。建议先看看加权最短作业优先（WSJF）模型，它在敏捷软件开发中被广泛使用。尤其是时间临界和风险降低，对这二者的度量是评估架构决策优先级的关键；认清自己的能力：不要在能力范围之外的事情上做决定。74/72十大技能3.简化如果你的解决方案是在做了很多假设的基础上提出来的，那么你的方案很可能是错的，也很可能会变得极其复杂。这个时候你就应该减少（简化）一些假设，以获得更好的解决方案。多方位观察解决方案：为了简化解决方案，经常需要你调整对解决方案的观察角度。75/72十大技能4.编程即使作为企业级架构师（最抽象的架构层级），你仍然应该了解开发人员的日常工作。如果你不了解开发如何完成的，那你可能会面临两个主要问题：开发人员不接受你的说法；你不了解开发人员的挑战和需求。76/72十大技能5.记录架构文档有时很重要，有时却不那么重要。例如，架构决策或代码指南是重要文档。在开始编程之前，通常需要初始文档，并且对此不断细化。因为代码也可以作为文档（如UML类图），所以有些文档可以自动生成。代码整洁：好的代码本身就是最好的文档。好的架构师应该拥有辨别好坏代码的能力。RobertC.Martin写的《CleanCode》就是这方面很好的学习资料。77/72十大技能6.沟通这是最被低估的技能之一。如果你在设计方面很出色，但不能表达你的想法，你的想法可能影响较小，甚至无法成功。确定沟通的人群level：不同的利益相关者有不同的兴趣和视角。不同的人群需要单独的针对某一级别的人群去定向沟通。在沟通之前，请确认你要沟通的人群，比如抽象性、内容、目标、动机等。比如开发人员关注一些解决方案的微小细节，而管理者更倾向怎么省钱。78/72十大技能7.评估了解基本的项目管理原则：作为架构师或首席开发人员，您经常被要求进行评估以实现您的想法：多长时间、多少人、多少人，哪些技能等等？当然，如果你计划引入新的工具或框架，你需要对这些“管理”问题有一个答案。79/72十大技能8.权衡质量是有代价的，如果过度使用架构，则会增加成本，并可能降低开发速度。应避免过度设计。解决矛盾目标：矛盾目标的典型例子是短期和长期目标。项目通常倾向于构建最简单的解决方案，而架构师则着眼于长远。通常，简单的解决方案不适合长期解决方案，并且有可能在以后被丢弃。考虑两件事：（1）开发人员和业务部门需要了解长期愿景及其好处，以便调整其解决方案；（2）负责预算的经理需要参与进来，以了解财务影响。没有必要直接将100%的长期愿景落实到位，但已开发的部分应该适合它。

80/72十大技能9.咨询和辅导在咨询和辅导方面，积极主动可能是你能做的最好的选择。如果有人问你，往往为时已晚。清理建筑工地是你想避免的事情。你需要以某种方式预见接下来的几周、几个月甚至几年，并为自己和组织做好下一步的准备。举行公开会议：误解或歧义的一个来源是缺乏沟通。留出一个固定的时间段，例如每周30分钟，以便与同事交流热门话题。81/72十大技能10.市场你的想法很棒，你已经很好地传达了它们，但仍然没有人愿意跟随？那么你可能缺乏营销技能。激励和说服：别人凭什么买你的产品？你需要展示产品的价值和好处。你可以说出几个核心的点，比如5个点或3个点，你需要包装的好，而且让别人容易理解（这里不是让你过分（虚假）包装，但包装是必要的）。没人喜欢一个整天穿着不整的人。82/72谢谢观看8-架构风格84概述在软件设计的不同阶段需要不同的设计方法。面对不同粒度，不同复杂度的系统，你需要使用不同的思考框架。体系结构设计与算法设计就需要不同的思考框架。在算法设计中，动态规划、贪心算法等这些算法思想是非常重要的思考方式/思考框架，他们在一定程度上能够保证快速得到计算的结果。它们面临的场景更多类似于“快速在某个字符串中快速寻找某个子串”，这样一些小问题。85概述算法虽然能够攻克粒度较小的问题，但是在构建系统的时候，往往面临的问题是：软件系统规模大且复杂性高。这时对系统的全局结构设计和规划更加重要。比如说，给你一个需求，设计一个图书管理系统，这时候动态规划这些思考框架就显得有些力不从心了。这时候，体系结构设计就应运而生了，体系结构设计是一种构建复杂系统时的思考框架，注意它服务的对象是粗粒度的复杂系统，所以你也不要奢望它能对你的算法设计有太大的帮助。86Agenda软件架构架构风格SOA与微服务87/72架构的概念软件体系结构（SoftwareArchitecture，又称为软件架构）包括❶构成系统的设计元素的描述、❷设计元素之间的交互、❸设计元素的组合模式以及❹在这些模式中的约束。88/72架构的概念理解的角度1：（集合角度）在计算机中，集合是我们一个有利的工具，我们定义事物，理解事物都可以从中获得启发。在集合中，你需要规定基本的元素（这里指构件），同时还需要制定这些元素的联系方式（这里是指元素的组合模式，及模式中的约束），适当的时候你还需要对具有某些特殊性质的元素进行分类（根据元素的作用，将元素分为了两大类：构件&连接件）接下来，你可以从利用常规的集合理论理解该思考框架了。89/72架构的概念理解的角度2：（实际意义）我们人类解决复杂问题的方式，基本都是采用分解的方式，即分而治之。所以给定一个系统的时候，我们尝试将其分解成不同的部分，按照一定的划分标准（比如，功能作用），我们可将其分出实际进行处理的模块（构件、连接件），以及负责连接（负责通信）的要素（分布，约束）等。举个简单的例子，以“人体”这个系统为例，根据人体各部分的功能，我们可将人体分为不同的构件：头、手、中间部位身体、腿。但是只具备这些要素还是不够的，他们必须连起来，相互配合才能形成真正的人体。90/72架构的概念91/72架构的概念软件体系结构=构件+连接件+约束。构件构件是具有某种功能的可复用的软件结构单元，表示系统中主要的计算元素和数据存储。构件是一个抽象的概念，在程序中可以指程序函数、模块、对象、类等。92/72架构的概念连接件连接是构件间建立、维护行为关联与信息传递的途径。连接包含下面两种要素：其中，机制指的实际中的消息传递方式。而协议则决定了消息的语义理解。93/72架构的概念连接件表示构件之间的交互并实现构件之间的连接。94/72架构的分类将架构分为业务架构、应用架构、云基础架构这几大类：业务架构主要着眼于控制业务的复杂性，基础架构着眼于解决分布式系统中存在的一系列问题。无论何种架构，都希望能实现系统的可变的同时、保障业务的高可用。另一个层面，根据企业中职责的划分，我们往往可以将软件架构，及关联的架构师划分为以下几类：业务架构/解决方案架构：❶核心是解决业务带来的系统复杂性，了解客户/业务方的痛点，项目定义，现有环境；❷梳理高阶需求和非功能性需求，进行问题域划分与领域建模等工作；❸沟通，方案建议，多次迭代，交付总体架构。95/72架构的分类应用架构：❶根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。❷并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，❸在保证系统的可用性和可维护性的同时，确保应用满足非功能属性要求（性能、安全、稳定性等）。❹96/72架构的分类数据架构：❶专注于构建数据中台，统一数据定义规范，标准化数据表达，形成有效易维护的数据资产。❷打造统一的大数据处理平台，包括数据可视化运营平台、数据共享平台、数据权限管理平台等。97/72架构的分类中间件架构：专注于中间件系统的构建，需要解决服务器负载，分布式服务的注册和发现，消息系统，缓存系统，分布式数据库等问题，同时架构师要在CAP【Consistency(一致性)Availability(可用性)Partitiontolerance(分区容忍性)】之间进行权衡。运维架构：负责运维系统的规划、选型、部署上线，建立规范化的运维体系。98/72架构的分类物理架构：物理架构关注软件元件是如何放到硬件上的，专注于基础设施，某种软硬件体系，甚至云平台，包括机房搭建、网络拓扑结构，网络分流器、代理服务器、Web服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。99/72Agenda软件架构架构风格SOA与微服务100/72软件构架风格软件架构风格（ArchitecturalStyles），也被称为架构模式，国内也有翻译为体系结构风格，换句话说是架构方面的套路。也可以说是前人在架构方面总结出来的，用以解决特定问题的方法。软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式（idiomaticparadigm）。架构风格定义了一个系统家族，即一个架构定义一个词汇表和一组约束。101/72软件构架风格词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件架构风格定义了用于描述系统的术语表，和一组指导构建系统的规则。102/72软件构架风格风格这个词是个模糊的概念，不同的人有不同的理解。通过数学集合的方式来定义风格。为了帮助理解体系结构风格，这里我们举一个现实生活中简单的例子。小明和小红是同班同学，他们在考试时有不同的表现，小明一般先做解答题，然后做选择题。小红则先做选择题，随后做解答题。这就成了两个人的做题风格的一部分。同样的构件（解答题，选择题），次序结构的不同，导致了两人不同的风格。103/72软件构架风格事实上，不同的风格有不同的适用场景。假设人的习惯是先解决简单的问题，再解决复杂的问题。那么（1）选择题难、解答题简单时，可以采取先解答题后选择题的做题风格；（2）选择题简单、解答题难时，可以采取先选择题后解答题的做题风格。同样，针对某种软件应用场景，应该选择与其相适应的构件，以及合理安排构件间的关系。在后面的具体体系结构风格中，可以重点查看构件、连接件、结构安排的不同。这些区分了不同的风格，适用于不同的场景。104/72软件构架风格软件架构设计的一个核心问题是能否使用重复的架构模式，即能否达到架构级的软件重用。也就是说，能否在不同的软件系统中，使用同一架构。当我们讨论软件架构时，常常会提及软件架构模式（ArchitecturalPattern）与软件架构风格（ArchitecturalStyle）。软件架构模式往往会用于具体地解决某个具体的重复的架构问题，而架构风格则是对于某个具体的架构设计方案的命名。软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式；架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效组织成一个完整的系统。105/72（1）分层架构分层架构（layeredarchitecture）是最常见的软件架构，也是事实上的标准架构。如果你不知道要用什么架构，那就用它。这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口通信。虽然没有明确约定，软件一定要分成多少层。四层的结构最常见。106/72（1）分层架构107/72（1）分层架构为什么不允许展示层直接访问数据库层呢，这样不是更快吗？这就是分层架构的另一个特征：层隔离(layersofisolation)。层隔离的概念意味着你对任何一层的改变都不会影响其它层，这很好理解。同时也意味着一个层的组件并不会了解其它层的实现，或者知道很少。比如业务层不需知道你持久层是如何具体实现的。分层架构也很容易增加新的层。108/72（1）分层架构在一个封闭的分层架构中，来自表示层的请求必须首先经过业务层，然后到达持久层，最后才能到达数据库层。109/72（1）分层架构表示层绕过任何不必要的层直接访问数据库以进行简单的检索请求会更快、更容易。要做到这一点，业务层和持久层必须是开放的，允许请求绕过其他层。开放层和封闭层哪个更好？这个问题的答案在于一个被称为隔离层的关键概念。隔离层概念意味着在架构的一个层中所做的更改通常不会影响其他层中的组件，只要这些层之间的契约保持不变。每一层都独立于其他层，因此对架构中其他层的内部工作原理知之甚少或一无所知。110/72（1）分层架构比如你想将一些通用的服务重构成一个服务层，比如通用图片处理，远程账户审计等，可以在业务层下增加一个服务层。它不会对展示层造成影响，也不会改变持久层的代码。上面的这个例子带来一个问题，因为每一层都是封闭的，业务层不得不通过服务层访问持久层，这没有天理啊。所以有时候你会创建一个开放的层。这意味着上一层可以绕过这一层直接访问下一层。有的在逻辑层和持久层之间，增加一个服务层(service)，提供不同业务逻辑需要一些接口，用户的请求将依次通过这四层的处理，不能跳过其中任何一层。111/72（1）分层架构虽然封闭层有助于隔离层，因此有助于隔离架构中的更改，但有时某些层开放是有意义的。例如，假设业务层中有共享对象，这些对象包含业务组件的公共功能（例如日期和字符串实用程序类、审计类、日志类等等）。假设有一个架构决策，表示层不能使用这些共享业务对象。112/72case:社区食堂点餐系统的分层架构设计（1）分层架构虚线从表示层组件到业务层中的共享业务对象。这个场景很难管理和控制，因为在架构上，表示层可以访问业务层，因此可以访问该层中的共享对象。113/72（1）分层架构从架构上强制执行此限制的一种方法是向架构添加一个包含所有共享业务对象的新服务层。现在添加这个新的层从架构上限制表示层访问共享业务对象，因为业务层是封闭的。但是，新的服务层必须标记为“开放”；否则业务层将被迫通过服务层来访问持久层。将服务层标记为“开放”允许业务层访问该层（实心箭头所示），或者绕过该层并向下转到下一层（虚线箭头所示）。114/72（1）分层架构115/72（1）分层架构分层架构风格是小型、简单的应用程序或网站的好选择。对于预算和时间限制非常紧张的情况，分层架构也是一个很好的架构选择，尤其是在开始阶段。由于架构简单性和开发人员和架构师之间对这种架构的熟悉度，分层架构可能是成本最低的架构风格之一，有助于小型应用的开发。当架构师仍在分析业务需求并且不确定哪种架构风格是最合适的时候，分层架构风格也是一个不错的选择。116/72（1）分层架构优点：结构简单，容易理解和开发。不同技能的程序员可以分工，负责不同的层，天然适合大多数软件公司的组织架构。每一层都可以独立测试，其它层的接口通过模拟解决。117/72（1）分层架构缺点：一旦环境变化，需要代码调整或者增加功能时，通常比较麻烦和费时部署比较麻烦，即使只修改一个小地方，往往需要整个软件重新部署，不容易做持续发布软件升级时，可能需要整个服务暂停扩展性差，用户请求大量增加时，必须依次扩展每一层，由于每一层内部是耦合的，扩展会比较困难。118/72（2）事件驱动架构事件驱动架构（EventDrivenArchitecture，EDA）是一个流行的分布式异步架构模式，可以用来设计规模很大的应用程序。基于这种架构模式应用可大可小。它由高度解耦的、单一目的的事件处理组件组成，可以异步地接收和处理事件。119/72（2）事件驱动架构120/72一个事件驱动系统典型地由事件消费者和事件产生者组成，事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。如果这个事件消费者是不可用的，事件管理者将保留这个事件，一段间隔之后再次转送该事件消费者。（2）事件驱动架构事件（event）是状态发生变化时，软件发出的通知。事件可以是多种多样的，比如一个机器测量达到一个阈值，或者一个特定的客户到达一个零售店。事件驱动架构（event-drivenarchitecture）就是通过事件进行通信的软件架构。它包括两个主要的拓扑结构：mediator和broker。Mediator拓扑结构需要你在一个事件通过mediator时精心安排好几个步骤，而broker拓扑结构无需mediator，而是由你串联起几个事件。121/72（2）事件驱动架构中介拓扑mediator通常用于：当你需要控制事件处理的工作流时，而代理拓扑broker则用于：当你需要对事件处理进行高度响应和动态控制的情况。由于这两种拓扑结构的架构特性和实现策略是不同的，所以理解每种拓扑结构以知道哪种拓扑结构最适合于特定情况是很重要的。122/72（2）事件驱动架构（1）Broker拓扑架构代理拓扑与中介拓扑的不同之处在于没有中央事件中介器。相反，消息流通过轻量级消息代理（如RabbitMQ、ActiveMQ、HornetQ等）以链式广播方式发布到多个事件处理器组件上。当你具有相对简单的事件处理流程并且不需要中央事件编排和协调时，此拓扑结构非常有用。代理拓扑中有四个主要的架构组件：一个启动事件、事件代理、一个事件处理器和一个处理事件。123/72（2）事件驱动架构124/722.单个事件处理器从事件代理中接受启动事件并开始处理该事件。1.启动事件是启动整个事件流的初始事件，它被发送到事件代理中的事件通道进行处理。3.接受启动事件的事件处理器执行与该事件处理相关联的特定任务，然后通过创建一个“处理事件”来异步地将它所做的事情对系统其余部分进行播报。4.如果需要，该处理事件将被异步发送到事件代理进行进一步处理。其他事件处理器监听此处理事件，通过执行某些操作对该事件作出反应，然后通过一个新的处理事件来公布他们所做的事情。5.这个过程一直持续直到没有人对最后一个事件处理器所做的事情感兴趣。事件代理（2）事件驱动架构125/721.假设作为一件复杂事件过程的一部分，生成一封电子邮件并发送给客户，通知他们所采取过的一个特定操作。2.Notification事件处理器将生成并发送电子邮件，然后通过发送到一个主题的新处理事件将该操作通告给系统的其余部分。3.没有其他事件处理器在监听有关该主题的事件，因此消息就这样消失了。（2）事件驱动架构这是架构可扩展性的一个很好的例子。虽然发送被忽略的消息似乎是在浪费资源，但事实并非如此。假设有一个新的需求出现来分析发送给客户的电子邮件。这个新的事件处理器可以以最小的工作量添加到整个系统中，因为电子邮件信息可以通过电子邮件主题提供给新的分析器而不必添加任何额外的基础设施或对其他事件处理器作出任何更改。126/72case：Broker拓扑架构-咖啡店订单系统（2）事件驱动架构为了说明代理拓扑是如何工作的，请考虑一个典型的零售订单输入系统中的处理流程，在这个系统中，为一个项目下订单（比如，像这样的一本书）。在本例中，OrderPlacement事件处理器接收启动事件（PlaceOrder），在数据库表中插入订单，并将订单ID返回给客户。然后，它通过order-created处理事件向系统其余部分通告它创建了一个订单。请注意，有三个事件处理器对该事件感兴趣：Notification事件处理器、Payment事件处理器和Inventory事件处理器。这三个事件处理器都在并行执行它们的任务。127/72（2）事件驱动架构128/721.Notification事件处理器接收order-created处理事件并向客户发送电子邮件。然后生成另一个处理事件（email-sent）。请注意，没有其他事件处理器在监听该事件。这是正常的，并说明了前面描述架构可扩展性的一个就绪钩子的示例，以便其他事件处理器最终可以在需要时访问该事件源。2.Inventory事件处理器监听order-created的处理事件，并减少该书相应的库存。然后，它通过一个inventory-updated处理事件来通告此操作，继而由Warehouse事件处理器提取该事件，以管理仓库之间的相应库存，并在供应量过低时重新编排物料。3.Payment事件处理器还接收order-created处理事件，并为刚刚创建的订单向客户的信用卡收费。4-1.通知系统其余部分已完成支付4-2.通知系统其他部分支付被拒绝5.OrderFulfillment事件处理器监听payment-applied处理事件，并执行订单拣选和打包。完成后，它会通过order-fulfilled处理事件向系统的其他部分通告它完成了订单。6.Notification事件通知客户订单已完成并准备好装运，同时Shipping事件处理器选择一种装运方法。Shipping事件处理器发送订单并发送order-shipped处理事件，Notification事件处理器还监听该事件以通知客户订单状态变更。（2）事件驱动架构所有的事件处理器都高度解耦并且彼此独立的。理解代理拓扑的最佳方法是将其视为接力赛。在一场接力赛中，赛跑者拿着接力棒（一根木棒）跑一段距离（比如1.5公里），然后把接力棒交给下一个赛跑者，如此下去，直到最后一个赛跑者越过终点线。在接力赛中，一旦一个赛跑者把接力棒交出去，这个赛跑者就完成了比赛并转向做其他事情。代理拓扑也是如此。一旦一个事件处理器移交事件，它就不再参与该特定事件的处理，可以对其他启动或处理事件作出反应。此外，每个事件处理器可以独立于其他处理器进行扩展。129/72（2）事件驱动架构（2）Mediator拓扑结构中介拓扑解决了前一节中描述的代理拓扑的一些缺点。此拓扑的中心是事件中介器，它管理和控制需要多个事件处理器协调的启动事件工作流。构成中介拓扑的架构组件包括一个启动事件、一个事件队列、一个事件中介器、多个事件通道和事件处理器。与代理拓扑一样，启动事件是开始整个事件过程的事件。与代理拓扑不同，启动事件被发送到一个由事件中介器接受的启动事件队列。130/72（2）事件驱动架构131/722.事件中介器只知道处理启动事件所涉及的步骤，因此生成相应的处理事件，这些事件以点到点消息传递方式发送到专用事件通道（通常是队列）3.事件处理器监听专用的事件通道，处理接收到的事件并通常向中介器返回他们已经完成工作的响应。与代理拓扑不同，中介拓扑中的事件处理器不会向系统的其余部分公布它们所做的事情。（2）事件驱动架构在中介拓扑的大多数实现中有多个中介器，通常与特定的领域或事件组相关联。这减少了与此种拓扑相关的单点故障问题，并提高了总体吞吐量和性能。例如，可能有一个客户中介器处理所有与客户相关的事件（例如新客户注册和档案更新），另一个中介器负责处理与订单相关的活动（例如将项目添加到购物车和签出）。132/72case：Mediator拓扑架构-挂号系统（2）事件驱动架构为了说明中介拓扑是如何工作的，请考虑前面的代理拓扑部分中描述的零售订单输入系统示例。但这次使用的是中介拓扑。在这个示例中，中介器知道处理此特定事件所需的步骤。这个事件流（中介器组件的内部）：133/72（2）事件驱动架构134/72（2）事件驱动架构135/721.当收到启动事件，Customer中介器生成一个create-order处理事件，并将此消息发送到order-placement-queue队列2.OrderPlacement事件处理器接受此事件，验证并创建订单，并将一个确认回复与订单ID一起返回给中介器。3.此时，中介器可能会将该订单ID发送回客户，示意订单已下单，或者可能必须继续直到所有步骤都完成（这将基于有关下订单的特定业务规则）。（2）事件驱动架构136/721.中介器现在转到第2步，同时生成三条消息：email-customer、apply-payment和adjust-inventory。这些处理事件都被发送到各自的队列。2.所有三个事件处理器都接收到这些消息和执行各自的任务，并通知中介器处理已完成。3.此时，如果某个并行事件处理器中发生错误，中介器可以采取纠正措施来解决问题中介器必须等到收到来自所有三个并行处理的确认回复之后，才能继续转到第3步。（2）事件驱动架构137/721.当中介器在步骤2中从所有事件处理器获得成功的确认，它就可以继续执行步骤3来执行订单2.OrderFulfillment和Warehouse事件处理器接受这些事件，执行它们的工作，并向中介器返回一个确认。请再次注意，这两个事件（fulfill-order和order-stock）可以同时发生。（2）事件驱动架构138/721.当这些事件完成后，中介器就转到第4步来发送订单。2.此步骤生成另一个email-customer处理事件，其中包含有关要执行的操作的特定信息（在本例中，通知客户订单已准备就绪）以及ship-order事件。（2）事件驱动架构139/721.最后，中介器转到第5步，并生成另一个上下文相关的email_customer事件，以通知客户订单已经发货。2.此时，工作流完成，中介器将启动事件流标记为完成，并删除与启动事件关联的所有状态。（2）事件驱动架构中介器组件拥有对工作流的知识和控制权，这是代理拓扑所不具备的。因为中介器控制工作流，所以它可以维护事件状态并管理错误处理、可恢复性和重启功能。例如，假设在前面的示例中，由于信用卡过期而未完成付款。在这种情况下，中介器接收到这个错误情况，并且知道在完成付款之前订单无法完成（步骤3），它会停止工作流并在自己的持久化数据存储中记录请求的状态。一旦最终完成了支付，工作流就可以从停止的地方重新启动（在本例中，是步骤3的开始）。140/72（2）事件驱动架构代理中介和中介拓扑之间的另一个差异是处理事件的意义和使用方式的不同。在代理拓扑示例中，处理事件被发布为系统中发生的事件（例如order-created、payment-applied和email-sent）事件处理器执行了一些操作，而其他事件处理程序则对该操作作出反应。然而在中介拓扑中，处理事件（如place-order、send-email和fulfill-order）是命令（需要发生的事情），而不是事件（已经发生的事情）。此外，在中介拓扑中，处理事件必须被处理（命令），而在代理拓扑中可以忽略它（反应）。141/72（3）微（内）核架构微（内）核架构（microkernelarchitecture）又称为“插件架构”（plug-inarchitecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。微核架构可以用来实现基于产品的应用比如Eclipse，在微内核的基础上添加一些插件，就可以提供不同的产品，如C++,Java等。微内核包含两个组件：内核系统coresystem和插件模块/组件plug-inmodules/components。应用逻辑被分隔成核心系统和插件模块，可以提供可扩展的、灵活的、特性隔离的功能。142/72（3）微（内）核架构内核（core）通常只包含系统运行的最小功能。插件则是互相独立的。插件之间的通信，应该减少到最低，避免出现互相依赖的问题。EclipseIDE是当之无愧的微内核的绝佳例子之一。微内核的架构模式可以嵌入到其它的架构模式之中。微内核架构通过插件还可以提供逐步演化的功能和增量开发。这种架构风格自然适合基于产品的应用（打包并可作为单个的整体部署进行下载和安装，通常作为第三方产品安装在客户站点上），但也广泛应用于许多非产品定制业务应用。143/72（3）微（内）核架构144/72（3）微（内）核架构（1）内核系统核心系统正式定义是：运行系统所需的最小功能。EclipseIDE就是一个很好的例子。Eclipse的核心系统只是一个基本的文本编辑器：打开一个文件，更改一些文本，然后保存文件。直到你添加了一些插件，Eclipse才开始成为一个有用的产品。例如，假设一个电子设备回收应用必须为收到的每个电子设备执行特定的自定义评估规则。用于此类处理的Java代码可能如下所示：145/72（3）微（内）核架构146/72（3）微（内）核架构与其将所有特定于某个客户的定制逻辑放在圈复杂度很高的核心系统中，不如为每个被评估的电子设备创建一个单独的插件组件会好很多。特定的客户插件组件不仅将独立的设备逻辑与其余的处理流程隔离开来，而且顾及到扩展性。添加一个新的要评估的电子设备只需：简单添加一个新的插件组件并更新注册表。对于微内核架构风格，评估一个电子设备只需要核心系统定位并调用相应的设备插件。147/72（3）微（内）核架构148/72（3）微（内）核架构根据规模和复杂性，核心系统可以实现为分层架构或模块化单体（下图）。在某些情况下，核心系统可以拆分为多个单独部署的领域服务，每个领域服务都包含特定于该领域的插件组件。例如，假设支付处理是表示核心系统的领域服务。每种支付方法（信用卡、Paypal、商店信用卡、礼品卡和购货单）都是特定于支付领域的独立插件组件。在上述例子中，通常整个单体应用共享一个数据库。149