软件设计与体系结构 7-架构风格

8-架构风格1概述在软件设计的不同阶段需要不同的设计方法。面对不同粒度，不同复杂度的系统，你需要使用不同的思考框架。体系结构设计与算法设计就需要不同的思考框架。在算法设计中，动态规划、贪心算法等这些算法思想是非常重要的思考方式/思考框架，他们在一定程度上能够保证快速得到计算的结果。它们面临的场景更多类似于“快速在某个字符串中快速寻找某个子串”，这样一些小问题。2概述算法虽然能够攻克粒度较小的问题，但是在构建系统的时候，往往面临的问题是：软件系统规模大且复杂性高。这时对系统的全局结构设计和规划更加重要。比如说，给你一个需求，设计一个图书管理系统，这时候动态规划这些思考框架就显得有些力不从心了。这时候，体系结构设计就应运而生了，体系结构设计是一种构建复杂系统时的思考框架，注意它服务的对象是粗粒度的复杂系统，所以你也不要奢望它能对你的算法设计有太大的帮助。3Agenda软件架构架构风格SOA与微服务4/72架构的概念软件体系结构（SoftwareArchitecture，又称为软件架构）包括❶构成系统的设计元素的描述、❷设计元素之间的交互、❸设计元素的组合模式以及❹在这些模式中的约束。5/72架构的概念理解的角度1：（集合角度）在计算机中，集合是我们一个有利的工具，我们定义事物，理解事物都可以从中获得启发。在集合中，你需要规定基本的元素（这里指构件），同时还需要制定这些元素的联系方式（这里是指元素的组合模式，及模式中的约束），适当的时候你还需要对具有某些特殊性质的元素进行分类（根据元素的作用，将元素分为了两大类：构件&连接件）接下来，你可以从利用常规的集合理论理解该思考框架了。6/72架构的概念理解的角度2：（实际意义）我们人类解决复杂问题的方式，基本都是采用分解的方式，即分而治之。所以给定一个系统的时候，我们尝试将其分解成不同的部分，按照一定的划分标准（比如，功能作用），我们可将其分出实际进行处理的模块（构件、连接件），以及负责连接（负责通信）的要素（分布，约束）等。举个简单的例子，以“人体”这个系统为例，根据人体各部分的功能，我们可将人体分为不同的构件：头、手、中间部位身体、腿。但是只具备这些要素还是不够的，他们必须连起来，相互配合才能形成真正的人体。7/72架构的概念8/72架构的概念软件体系结构=构件+连接件+约束。构件构件是具有某种功能的可复用的软件结构单元，表示系统中主要的计算元素和数据存储。构件是一个抽象的概念，在程序中可以指程序函数、模块、对象、类等。9/72架构的概念连接件连接是构件间建立、维护行为关联与信息传递的途径。连接包含下面两种要素：其中，机制指的实际中的消息传递方式。而协议则决定了消息的语义理解。10/72架构的概念连接件表示构件之间的交互并实现构件之间的连接。11/72架构的分类将架构分为业务架构、应用架构、云基础架构这几大类：业务架构主要着眼于控制业务的复杂性，基础架构着眼于解决分布式系统中存在的一系列问题。无论何种架构，都希望能实现系统的可变的同时、保障业务的高可用。另一个层面，根据企业中职责的划分，我们往往可以将软件架构，及关联的架构师划分为以下几类：业务架构/解决方案架构：❶核心是解决业务带来的系统复杂性，了解客户/业务方的痛点，项目定义，现有环境；❷梳理高阶需求和非功能性需求，进行问题域划分与领域建模等工作；❸沟通，方案建议，多次迭代，交付总体架构。12/72架构的分类应用架构：❶根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。❷并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，❸在保证系统的可用性和可维护性的同时，确保应用满足非功能属性要求（性能、安全、稳定性等）。❹13/72架构的分类数据架构：❶专注于构建数据中台，统一数据定义规范，标准化数据表达，形成有效易维护的数据资产。❷打造统一的大数据处理平台，包括数据可视化运营平台、数据共享平台、数据权限管理平台等。14/72架构的分类中间件架构：专注于中间件系统的构建，需要解决服务器负载，分布式服务的注册和发现，消息系统，缓存系统，分布式数据库等问题，同时架构师要在CAP【Consistency(一致性)Availability(可用性)Partitiontolerance(分区容忍性)】之间进行权衡。运维架构：负责运维系统的规划、选型、部署上线，建立规范化的运维体系。15/72架构的分类物理架构：物理架构关注软件元件是如何放到硬件上的，专注于基础设施，某种软硬件体系，甚至云平台，包括机房搭建、网络拓扑结构，网络分流器、代理服务器、Web服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。16/72Agenda软件架构架构风格SOA与微服务17/72软件构架风格软件架构风格（ArchitecturalStyles），也被称为架构模式，国内也有翻译为体系结构风格，换句话说是架构方面的套路。也可以说是前人在架构方面总结出来的，用以解决特定问题的方法。软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式（idiomaticparadigm）。架构风格定义了一个系统家族，即一个架构定义一个词汇表和一组约束。18/72软件构架风格词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件架构风格定义了用于描述系统的术语表，和一组指导构建系统的规则。19/72软件构架风格风格这个词是个模糊的概念，不同的人有不同的理解。通过数学集合的方式来定义风格。为了帮助理解体系结构风格，这里我们举一个现实生活中简单的例子。小明和小红是同班同学，他们在考试时有不同的表现，小明一般先做解答题，然后做选择题。小红则先做选择题，随后做解答题。这就成了两个人的做题风格的一部分。同样的构件（解答题，选择题），次序结构的不同，导致了两人不同的风格。20/72软件构架风格事实上，不同的风格有不同的适用场景。假设人的习惯是先解决简单的问题，再解决复杂的问题。那么（1）选择题难、解答题简单时，可以采取先解答题后选择题的做题风格；（2）选择题简单、解答题难时，可以采取先选择题后解答题的做题风格。同样，针对某种软件应用场景，应该选择与其相适应的构件，以及合理安排构件间的关系。在后面的具体体系结构风格中，可以重点查看构件、连接件、结构安排的不同。这些区分了不同的风格，适用于不同的场景。21/72软件构架风格软件架构设计的一个核心问题是能否使用重复的架构模式，即能否达到架构级的软件重用。也就是说，能否在不同的软件系统中，使用同一架构。当我们讨论软件架构时，常常会提及软件架构模式（ArchitecturalPattern）与软件架构风格（ArchitecturalStyle）。软件架构模式往往会用于具体地解决某个具体的重复的架构问题，而架构风格则是对于某个具体的架构设计方案的命名。软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式；架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效组织成一个完整的系统。22/72（1）分层架构分层架构（layeredarchitecture）是最常见的软件架构，也是事实上的标准架构。如果你不知道要用什么架构，那就用它。这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口通信。虽然没有明确约定，软件一定要分成多少层。四层的结构最常见。23/72（1）分层架构24/72（1）分层架构为什么不允许展示层直接访问数据库层呢，这样不是更快吗？这就是分层架构的另一个特征：层隔离(layersofisolation)。层隔离的概念意味着你对任何一层的改变都不会影响其它层，这很好理解。同时也意味着一个层的组件并不会了解其它层的实现，或者知道很少。比如业务层不需知道你持久层是如何具体实现的。分层架构也很容易增加新的层。25/72（1）分层架构在一个封闭的分层架构中，来自表示层的请求必须首先经过业务层，然后到达持久层，最后才能到达数据库层。26/72（1）分层架构表示层绕过任何不必要的层直接访问数据库以进行简单的检索请求会更快、更容易。要做到这一点，业务层和持久层必须是开放的，允许请求绕过其他层。开放层和封闭层哪个更好？这个问题的答案在于一个被称为隔离层的关键概念。隔离层概念意味着在架构的一个层中所做的更改通常不会影响其他层中的组件，只要这些层之间的契约保持不变。每一层都独立于其他层，因此对架构中其他层的内部工作原理知之甚少或一无所知。27/72（1）分层架构比如你想将一些通用的服务重构成一个服务层，比如通用图片处理，远程账户审计等，可以在业务层下增加一个服务层。它不会对展示层造成影响，也不会改变持久层的代码。上面的这个例子带来一个问题，因为每一层都是封闭的，业务层不得不通过服务层访问持久层，这没有天理啊。所以有时候你会创建一个开放的层。这意味着上一层可以绕过这一层直接访问下一层。有的在逻辑层和持久层之间，增加一个服务层(service)，提供不同业务逻辑需要一些接口，用户的请求将依次通过这四层的处理，不能跳过其中任何一层。28/72（1）分层架构虽然封闭层有助于隔离层，因此有助于隔离架构中的更改，但有时某些层开放是有意义的。例如，假设业务层中有共享对象，这些对象包含业务组件的公共功能（例如日期和字符串实用程序类、审计类、日志类等等）。假设有一个架构决策，表示层不能使用这些共享业务对象。29/72case:社区食堂点餐系统的分层架构设计（1）分层架构虚线从表示层组件到业务层中的共享业务对象。这个场景很难管理和控制，因为在架构上，表示层可以访问业务层，因此可以访问该层中的共享对象。30/72（1）分层架构从架构上强制执行此限制的一种方法是向架构添加一个包含所有共享业务对象的新服务层。现在添加这个新的层从架构上限制表示层访问共享业务对象，因为业务层是封闭的。但是，新的服务层必须标记为“开放”；否则业务层将被迫通过服务层来访问持久层。将服务层标记为“开放”允许业务层访问该层（实心箭头所示），或者绕过该层并向下转到下一层（虚线箭头所示）。31/72（1）分层架构32/72（1）分层架构分层架构风格是小型、简单的应用程序或网站的好选择。对于预算和时间限制非常紧张的情况，分层架构也是一个很好的架构选择，尤其是在开始阶段。由于架构简单性和开发人员和架构师之间对这种架构的熟悉度，分层架构可能是成本最低的架构风格之一，有助于小型应用的开发。当架构师仍在分析业务需求并且不确定哪种架构风格是最合适的时候，分层架构风格也是一个不错的选择。33/72（1）分层架构优点：结构简单，容易理解和开发。不同技能的程序员可以分工，负责不同的层，天然适合大多数软件公司的组织架构。每一层都可以独立测试，其它层的接口通过模拟解决。34/72（1）分层架构缺点：一旦环境变化，需要代码调整或者增加功能时，通常比较麻烦和费时部署比较麻烦，即使只修改一个小地方，往往需要整个软件重新部署，不容易做持续发布软件升级时，可能需要整个服务暂停扩展性差，用户请求大量增加时，必须依次扩展每一层，由于每一层内部是耦合的，扩展会比较困难。35/72（2）事件驱动架构事件驱动架构（EventDrivenArchitecture，EDA）是一个流行的分布式异步架构模式，可以用来设计规模很大的应用程序。基于这种架构模式应用可大可小。它由高度解耦的、单一目的的事件处理组件组成，可以异步地接收和处理事件。36/72（2）事件驱动架构37/72一个事件驱动系统典型地由事件消费者和事件产生者组成，事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。如果这个事件消费者是不可用的，事件管理者将保留这个事件，一段间隔之后再次转送该事件消费者。（2）事件驱动架构事件（event）是状态发生变化时，软件发出的通知。事件可以是多种多样的，比如一个机器测量达到一个阈值，或者一个特定的客户到达一个零售店。事件驱动架构（event-drivenarchitecture）就是通过事件进行通信的软件架构。它包括两个主要的拓扑结构：mediator和broker。Mediator拓扑结构需要你在一个事件通过mediator时精心安排好几个步骤，而broker拓扑结构无需mediator，而是由你串联起几个事件。38/72（2）事件驱动架构中介拓扑mediator通常用于：当你需要控制事件处理的工作流时，而代理拓扑broker则用于：当你需要对事件处理进行高度响应和动态控制的情况。由于这两种拓扑结构的架构特性和实现策略是不同的，所以理解每种拓扑结构以知道哪种拓扑结构最适合于特定情况是很重要的。39/72（2）事件驱动架构（1）Broker拓扑架构代理拓扑与中介拓扑的不同之处在于没有中央事件中介器。相反，消息流通过轻量级消息代理（如RabbitMQ、ActiveMQ、HornetQ等）以链式广播方式发布到多个事件处理器组件上。当你具有相对简单的事件处理流程并且不需要中央事件编排和协调时，此拓扑结构非常有用。代理拓扑中有四个主要的架构组件：一个启动事件、事件代理、一个事件处理器和一个处理事件。40/72（2）事件驱动架构41/722.单个事件处理器从事件代理中接受启动事件并开始处理该事件。1.启动事件是启动整个事件流的初始事件，它被发送到事件代理中的事件通道进行处理。3.接受启动事件的事件处理器执行与该事件处理相关联的特定任务，然后通过创建一个“处理事件”来异步地将它所做的事情对系统其余部分进行播报。4.如果需要，该处理事件将被异步发送到事件代理进行进一步处理。其他事件处理器监听此处理事件，通过执行某些操作对该事件作出反应，然后通过一个新的处理事件来公布他们所做的事情。5.这个过程一直持续直到没有人对最后一个事件处理器所做的事情感兴趣。事件代理（2）事件驱动架构42/721.假设作为一件复杂事件过程的一部分，生成一封电子邮件并发送给客户，通知他们所采取过的一个特定操作。2.Notification事件处理器将生成并发送电子邮件，然后通过发送到一个主题的新处理事件将该操作通告给系统的其余部分。3.没有其他事件处理器在监听有关该主题的事件，因此消息就这样消失了。（2）事件驱动架构这是架构可扩展性的一个很好的例子。虽然发送被忽略的消息似乎是在浪费资源，但事实并非如此。假设有一个新的需求出现来分析发送给客户的电子邮件。这个新的事件处理器可以以最小的工作量添加到整个系统中，因为电子邮件信息可以通过电子邮件主题提供给新的分析器而不必添加任何额外的基础设施或对其他事件处理器作出任何更改。43/72case：Broker拓扑架构-咖啡店订单系统（2）事件驱动架构为了说明代理拓扑是如何工作的，请考虑一个典型的零售订单输入系统中的处理流程，在这个系统中，为一个项目下订单（比如，像这样的一本书）。在本例中，OrderPlacement事件处理器接收启动事件（PlaceOrder），在数据库表中插入订单，并将订单ID返回给客户。然后，它通过order-created处理事件向系统其余部分通告它创建了一个订单。请注意，有三个事件处理器对该事件感兴趣：Notification事件处理器、Payment事件处理器和Inventory事件处理器。这三个事件处理器都在并行执行它们的任务。44/72（2）事件驱动架构45/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公里），然后把接力棒交给下一个赛跑者，如此下去，直到最后一个赛跑者越过终点线。在接力赛中，一旦一个赛跑者把接力棒交出去，这个赛跑者就完成了比赛并转向做其他事情。代理拓扑也是如此。一旦一个事件处理器移交事件，它就不再参与该特定事件的处理，可以对其他启动或处理事件作出反应。此外，每个事件处理器可以独立于其他处理器进行扩展。46/72（2）事件驱动架构（2）Mediator拓扑结构中介拓扑解决了前一节中描述的代理拓扑的一些缺点。此拓扑的中心是事件中介器，它管理和控制需要多个事件处理器协调的启动事件工作流。构成中介拓扑的架构组件包括一个启动事件、一个事件队列、一个事件中介器、多个事件通道和事件处理器。与代理拓扑一样，启动事件是开始整个事件过程的事件。与代理拓扑不同，启动事件被发送到一个由事件中介器接受的启动事件队列。47/72（2）事件驱动架构48/722.事件中介器只知道处理启动事件所涉及的步骤，因此生成相应的处理事件，这些事件以点到点消息传递方式发送到专用事件通道（通常是队列）3.事件处理器监听专用的事件通道，处理接收到的事件并通常向中介器返回他们已经完成工作的响应。与代理拓扑不同，中介拓扑中的事件处理器不会向系统的其余部分公布它们所做的事情。（2）事件驱动架构在中介拓扑的大多数实现中有多个中介器，通常与特定的领域或事件组相关联。这减少了与此种拓扑相关的单点故障问题，并提高了总体吞吐量和性能。例如，可能有一个客户中介器处理所有与客户相关的事件（例如新客户注册和档案更新），另一个中介器负责处理与订单相关的活动（例如将项目添加到购物车和签出）。49/72case：Mediator拓扑架构-挂号系统（2）事件驱动架构为了说明中介拓扑是如何工作的，请考虑前面的代理拓扑部分中描述的零售订单输入系统示例。但这次使用的是中介拓扑。在这个示例中，中介器知道处理此特定事件所需的步骤。这个事件流（中介器组件的内部）：50/72（2）事件驱动架构51/72（2）事件驱动架构52/721.当收到启动事件，Customer中介器生成一个create-order处理事件，并将此消息发送到order-placement-queue队列2.OrderPlacement事件处理器接受此事件，验证并创建订单，并将一个确认回复与订单ID一起返回给中介器。3.此时，中介器可能会将该订单ID发送回客户，示意订单已下单，或者可能必须继续直到所有步骤都完成（这将基于有关下订单的特定业务规则）。（2）事件驱动架构53/721.中介器现在转到第2步，同时生成三条消息：email-customer、apply-payment和adjust-inventory。这些处理事件都被发送到各自的队列。2.所有三个事件处理器都接收到这些消息和执行各自的任务，并通知中介器处理已完成。3.此时，如果某个并行事件处理器中发生错误，中介器可以采取纠正措施来解决问题中介器必须等到收到来自所有三个并行处理的确认回复之后，才能继续转到第3步。（2）事件驱动架构54/721.当中介器在步骤2中从所有事件处理器获得成功的确认，它就可以继续执行步骤3来执行订单2.OrderFulfillment和Warehouse事件处理器接受这些事件，执行它们的工作，并向中介器返回一个确认。请再次注意，这两个事件（fulfill-order和order-stock）可以同时发生。（2）事件驱动架构55/721.当这些事件完成后，中介器就转到第4步来发送订单。2.此步骤生成另一个email-customer处理事件，其中包含有关要执行的操作的特定信息（在本例中，通知客户订单已准备就绪）以及ship-order事件。（2）事件驱动架构56/721.最后，中介器转到第5步，并生成另一个上下文相关的email_customer事件，以通知客户订单已经发货。2.此时，工作流完成，中介器将启动事件流标记为完成，并删除与启动事件关联的所有状态。（2）事件驱动架构中介器组件拥有对工作流的知识和控制权，这是代理拓扑所不具备的。因为中介器控制工作流，所以它可以维护事件状态并管理错误处理、可恢复性和重启功能。例如，假设在前面的示例中，由于信用卡过期而未完成付款。在这种情况下，中介器接收到这个错误情况，并且知道在完成付款之前订单无法完成（步骤3），它会停止工作流并在自己的持久化数据存储中记录请求的状态。一旦最终完成了支付，工作流就可以从停止的地方重新启动（在本例中，是步骤3的开始）。57/72（2）事件驱动架构代理中介和中介拓扑之间的另一个差异是处理事件的意义和使用方式的不同。在代理拓扑示例中，处理事件被发布为系统中发生的事件（例如order-created、payment-applied和email-sent）事件处理器执行了一些操作，而其他事件处理程序则对该操作作出反应。然而在中介拓扑中，处理事件（如place-order、send-email和fulfill-order）是命令（需要发生的事情），而不是事件（已经发生的事情）。此外，在中介拓扑中，处理事件必须被处理（命令），而在代理拓扑中可以忽略它（反应）。58/72（3）微（内）核架构微（内）核架构（microkernelarchitecture）又称为“插件架构”（plug-inarchitecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。微核架构可以用来实现基于产品的应用比如Eclipse，在微内核的基础上添加一些插件，就可以提供不同的产品，如C++,Java等。微内核包含两个组件：内核系统coresystem和插件模块/组件plug-inmodules/components。应用逻辑被分隔成核心系统和插件模块，可以提供可扩展的、灵活的、特性隔离的功能。59/72（3）微（内）核架构内核（core）通常只包含系统运行的最小功能。插件则是互相独立的。插件之间的通信，应该减少到最低，避免出现互相依赖的问题。EclipseIDE是当之无愧的微内核的绝佳例子之一。微内核的架构模式可以嵌入到其它的架构模式之中。微内核架构通过插件还可以提供逐步演化的功能和增量开发。这种架构风格自然适合基于产品的应用（打包并可作为单个的整体部署进行下载和安装，通常作为第三方产品安装在客户站点上），但也广泛应用于许多非产品定制业务应用。60/72（3）微（内）核架构61/72（3）微（内）核架构（1）内核系统核心系统正式定义是：运行系统所需的最小功能。EclipseIDE就是一个很好的例子。Eclipse的核心系统只是一个基本的文本编辑器：打开一个文件，更改一些文本，然后保存文件。直到你添加了一些插件，Eclipse才开始成为一个有用的产品。例如，假设一个电子设备回收应用必须为收到的每个电子设备执行特定的自定义评估规则。用于此类处理的Java代码可能如下所示：62/72（3）微（内）核架构63/72（3）微（内）核架构与其将所有特定于某个客户的定制逻辑放在圈复杂度很高的核心系统中，不如为每个被评估的电子设备创建一个单独的插件组件会好很多。特定的客户插件组件不仅将独立的设备逻辑与其余的处理流程隔离开来，而且顾及到扩展性。添加一个新的要评估的电子设备只需：简单添加一个新的插件组件并更新注册表。对于微内核架构风格，评估一个电子设备只需要核心系统定位并调用相应的设备插件。64/72（3）微（内）核架构65/72（3）微（内）核架构根据规模和复杂性，核心系统可以实现为分层架构或模块化单体（下图）。在某些情况下，核心系统可以拆分为多个单独部署的领域服务，每个领域服务都包含特定于该领域的插件组件。例如，假设支付处理是表示核心系统的领域服务。每种支付方法（信用卡、Paypal、商店信用卡、礼品卡和购货单）都是特定于支付领域的独立插件组件。在上述例子中，通常整个单体应用共享一个数据库。66/72（3）微（内）核架构67/72分层架构（3）微（内）核架构68/72模块化单体（3）微（内）核架构（2）插件组件插件组件是独立的、互不影响的组件，包含用于增强或扩展核心系统的专门的处理、附加功能和定制化代码。此外，它们还可以用于隔离高度易变性的代码，从而在应用中建立更好的可维护性和可测试性。理想情况下，插件组件应该彼此独立，并且它们之间没有任何依赖关系。69/72（3）微（内）核架构插件组件和核心系统之间的通信通常是点对点的，这意味着将插件连接到核心系统的“管道”通常是对插件组件的入口类的一个方法或函数调用。此外，插件组件可以是基于编译的，也可以是基于运行时的。点对点插件组件可以实现为共享库（如JAR、DLL或Gem）、Java中的包名或C#中的命名空间。继续以电子设备回收评估应用为例，每个电子设备插件可以编写并实现为一个JAR、DLL或RubyGem（或任何其他共享库），设备名称与独立共享库的名称匹配。70/72（3）微（内）核架构71/72（3）微（内）核架构72/72插件组件不一定总是与核心系统进行点对点通信。（3）微（内）核架构（3）注册表核心系统需要知道哪些插件模块可用，以及如何访问它们。一种常见方法是通过插件注册表来实现。注册表包含有关每个插件模块的信息，包括其名称、数据契约和远程访问协议详细信息（取决于插件与核心系统的连接方式）。例如，标记高风险税务审计项目的税务软件插件可能具有包含服务名称（AuditChecker）、数据契约（输入数据和输出数据）和契约格式（XML）的注册表项。73/72（3）微（内）核架构74/72（3）微（内）核架构75/72（4）契约插件组件和核心系统之间的契约通常是：跨插件组件领域的标准协议，包括从插件组件返回的行为、输入数据和输出数据。自定义契约通常会在插件组件由第三方开发，你无法控制插件所使用的契约的情况下建立。在这种情况下，通常在插件契约和你的标准契约之间创建一个适配器，这样核心系统就不需要为每个插件编写专门的代码。（3）微（内）核架构76/72在这个契约示例中，设备评估插件将以格式化字符串的形式返回评估报告；转售标志（true或false），表明该设备是否可以在第三方市场转售或被安全处置；最后，如果它可以转售（另一种形式的回收），那么设备的价值是多少，建议转售价格应该是多少。（4）微服务架构在Web应用程序发展的早期，大部分工程是将所有的服务端功能模块打包到单个巨石型（Monolith）应用中，即单体架构。譬如很多企业的Java应用程序打包为war包，最终会形成如下的架构：77/72（4）微服务架构“单体”这个名称，是在微服务流行之后，“事后追认”所形成的的概念。此前，没有多少人将“单体”看作一种架构。很少有教如何开发单体架构的开发资料。这一方面体现单体架构的简单性，另外一方面体现出在相当长时间里，大家已经习惯了软件架构就是单体的这种样子。单体不一定就不好，一般有问题的是“大型单体系统”，而不是小型单体系统。对于小型系统，单台机器足以支撑起良好的运行系统，不仅易于开发、测试、部署，而且系统中各个功能、模块、方法的调用都是进程内调用，不会发生进程间通信（Inter-ProcessCommunication,IPC）,因此，运行效率也是最高的。78/72（4）微服务架构单体系统一般也是分层的。分层架构（LayeredArchitecture）是现在所有系统中普遍认可，采用的软件设计方法，无论是单体还是微服务，亦或是其他架构风格，都会对代码进行纵向层次划分。如果常见的：表示层-》业务层-》持久层-》数据库层，像目前很多传统企业都在用的SpringMVC框架、SSH框架、SSM框架等都可以发布到单体服务器进行应用。比如Java开发者典型的部署方式如下图所示79/72（4）微服务架构80/72（4）微服务架构81/72从分布式部署架构上延伸出来的集群概念：所谓集群就是，相同的事情多个人做。比如在上图分布式系统中，“商品服务”被部署到一台机器上，但是如果在购物节时，请求太多，一台机器根本扛不住，这时我们也增加10台机器，这10台机器都部署商品服务,这样由这10台机器就组成了商品服务集群，集群的初衷就是提高系统的吞吐量。另一个就是提高可用性，比如一台服务器挂了，不至于服务不可用。虽然分布式架构能解决一系列问题，但是它经常和后面说的SOA、微服务架构结合使用，分布式架构是从软件部署层面来描述的。它固然也存在很多复杂的问题，如事物一致性等。（4）微服务架构82/72单体架构也支持按照技术、功能、职责等维度，将软件拆分为各种模块，以便重用和管理代码。单体系统并不意味只有一个整体的程序封装形式，如果需要，它完全可以由多个JAR，WAR，DDL，Assembly或者其他模块格式来构成。从横向扩展（ScaleHorizontally）角度衡量，在负载均衡器之后同时部署若干个单体副本系统，以达到分摊流量压力的效果。（4）微服务架构83/72单体应用易于搭建开发环境、易于测试、易于部署；其缺陷也非常明显，无法进行局部改动与部署，编译时间过长，回归测试周期过长，开发效率降低等。（4）微服务架构84/72微服务架构（microservicesarchitecture）是面向服务架构（service-orientedarchitecture，缩写SOA）的升级。每一个服务就是一个独立的部署单元（separatelydeployedunit）。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。（4）微服务架构85/72（4）微服务架构86/72微前端：前端可以是富桌面、移动或web应用（5）云架构云架构有时候也被成为基于空间的架构（Space-basedArchitecture）。大部分的基于Web的应用的业务流都是一样的。客户端的请求发送给web服务器，然后是应用服务器，最后是数据库服务器。对于用户很小时不会有问题，但是负载增大时就会遇到瓶颈（想想抢火车票）。首先是web服务器撑不住，web服务器能撑住应用服务器又不行，然后是数据库服务器。通常解决方案是增加web服务器，便宜，简单，但很多情况下负载会传递给应用服务器，然后传递给数据库服务器。87/72（5）云架构对于解决用户负载增加产生的瓶颈，通常的反应是横向扩展web服务器。这是相对容易和便宜的方案，它有时可以解决瓶颈问题。然而，在大多数高用户负载的情况下，扩展web服务器层只会将瓶颈向下移动到应用服务器。扩展应用程序服务器可能比web服务器更复杂、更昂贵，而且通常只会将瓶颈转移到数据库服务器上，而数据库服务器的扩展则更加困难和昂贵。因为数据库也有锁，有事务的限制。88/72（5）云架构在任何具有大量并发用户负载的大容量应用中，数据库通常是你可以并发处理多少事务的最终限制因素。如图，最容易扩展的是WebServer，而最难扩展的DBServer。虽然各种缓存技术和数据库扩展产品有助于解决这些问题，但事实仍然是，为极端负载扩展普通应用程序是一个非常困难的命题。基于空间的架构风格是专门为解决涉及高可扩展性、弹性和高并发性问题而设计的。对于具有可变和不可预测的并发用户量的应用，它也是一种有用的架构风格。从架构上解决极端和可变的可扩展性问题通常比尝试扩展数据库或将缓存技术改造为不可扩展的架构要好。云架构是最容易扩展的架构。89/72（5）云架构90/72（5）云架构分成两部分：处理单元（processingunit）和虚拟中间件（virtualizedmiddleware）。（1）处理单元：实现业务逻辑。（2）虚拟中间件：负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。处理网格是虚拟化中间件中的一个可选组件，当单个业务请求中涉及多个处理单元时，它管理编排好的请求处理。如果请求需要处理单元类型（例如，订单处理单元和付款处理单元）之间的协调，则处理网格将在这两个处理单元之间协调和编排请求。91/72（5）云架构虚拟中间件又包含四个组件。消息传递网格（MessagingGrid）：管理用户请求和session，当一个请求进来以后，决定分配给哪一个处理单元。数据网格（DataGrid）：将数据复制到每一个处理单元，即数据同步。保证某个处理单元都得到同样的数据。处理网格（ProcessingGrid）：可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元部署管理器（DeploymentManager）：负责处理单元的启动和关闭，监控负载和响应时间：当负载增加就新启动处理单元，负载减少就关闭处理单元。92/72（5）云架构93/72（5）云架构云架构非常适合于用户或请求量剧增的应用，以及吞吐量超过10000个并发用户的应用（每个请求需要执行1秒完成,那么在并发10000的前提下TPS是10000）音乐会票务系统有一个独特的问题：在一场流行音乐会宣布之前，并发用户量相对较低。一旦音乐会门票开始销售，用户量通常会从几百个并发用户激增到几千个（可能是上万个，具体取决于哪一场演唱会），所有人都试图获得音乐会的门票（并希望是好的座位！）。门票通常在几分钟内就会卖完，这需要基于空间的架构所支持的架构特性来支持。94/72case：云端外卖订餐平台（5）云架构与这种系统相关的挑战很多。❶首先，不管座位偏好如何，门票的数量是一定的。考虑到大量并发请求，座位是否可以预定的信息必须不断更新并且尽可能快地提供。❷假设指定座位是一个选项，座位可用性也必须尽快更新。对于这种类型的系统，连续地同步访问一个中央数据库可能行不通。对于一个典型的数据库来说，在这种规模和更新频率的水平上，通过标准数据库事务来处理数以万计的并发请求是非常困难的。95/72（5）云架构基于空间的体系结构非常适合音乐会售票系统，因为这种应用需要高弹性。想要购买音乐会门票的并发用户数量的瞬时增加会立即被部署管理器发现，而部署管理器又会启动大量的处理单元来处理大量的请求。最佳情况下，部署管理器将被配置为：在门票发售之前不久启动所需数量的处理单元，因此在用户负载显著增加之前让这些实例处于待命状态。96/72Agenda软件架构架构风格SOA与微服务97/72SOA与微服务过去十几年，随着互联网发展以及业务的多样化，系统的架构也在不断发生变化，总体上来说大体经历了：从单体应用架构-垂直应用架构-分布式架构-SOA架构-微服务架构的演变，当前各大企业都在朝着数字化转型和云原生方向前进。“架构要解决业务需求的问题，业务需求的变化驱动着架构的进化”。从互联网的角度出发，结合业务的主要变化，国内软件架构这15年的发展大致可以分为三个阶段。98/72SOA与微服务第一阶段，互联网正式爆发。这一阶段的特点是网页与用户数据的迅速增多，无论是当时流行的搜索引擎、社交网络，还是工业、电商等行业互联网的爆发带来的数据量是传统的单机和简单的架构模式无法支持的，传统的架构也无法解决相应的业务问题。因此，软件架构就慢慢从原来的单机系统演变成分布式系统，以解决新业务形态带来的问题，诸如在架构层面考虑容错、负载均衡等问题。同时需要注意的是，也正是这个时候开启了后来所谓的大数据时代。99/72SOA与微服务第二阶段，移动互联网的兴起。移动互联网兴起之后，互联网业务的形式又随之发生了比较大的变化。PC互联网时代比较典型的一个例子就是搜索引擎，搜索引擎对时效性要求并不是特别高，对用户来说只要能找到所需要的内容即可，不追求实时在线，这个时候架构更多解决的是吞吐量大的问题。移动时代则不同，推荐、个性化服务已经成为更主流的方式，业务的场景也变成了：对实时性要求非常高的情况。100/72SOA与微服务这一阶段架构方面主要的变化就是计算从以前的批量计算变成了流式计算，数据处理从离线变成实时，比较典型的例子就是Hadoop到Spark，再到后面Flink的变化。这其中的变化就涵盖了系统架构对用户数据的处理、文档数据的处理、推荐、广告算法等等，这个时期业务对架构的范式要求更高。另外，这一时期硬件等基础设施的大幅提升与大规模的应用，也对架构的演进起到了非常大的推动作用。101/72SOA与微服务第三阶段，云原生时代。也就是当下，企业上云对许多公司来说已经变成一种默认行为。这个时候业务架构就需要基于云原生进行改造：如何基于云组件做适配，如何合理使用云的弹性、计算存储分离等功能也变的至关重要。如果继续使用老的业务架构跑在云上，那无异于“拉着马车跑在高速公路上”。102/72SOA与微服务云原生出现之后还衍生了一个有趣的现象，在云原生到来之前，企业软件架构与互联网软件架构是分离的，现在这两者已经开始慢慢交融在一起。传统的厂商需要进行数字化转型，其面临的业务需要互联网化，要解决高并发、大吞吐等问题，势必要采用互联网架构。互联网公司经过多年的发展壮大，内部运营管理上也会面临传统企业的问题：比如如何解决开发效率，如何解决新老系统并存，如何进行数据打通等等。总的来说，业务场景的需求变化驱动着架构的演进。103/72SOA与微服务SOA全称是ServiceOrientedArchitecture，中文释义为“面向服务的架构”，它是一种设计理念，其中包含多个服务，服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行，服务之间通过网络进行调用。它是一种在计算机环境中设计、开发、部署和管理离散模型的方法。在当前微服务，中台和云原生技术下，传统的SOA是否已经过时？出去跟别人交流，谈到SOA的时候有些客户直接的反馈就是过时的技术怎么还在用？或者一说到SOA就认为过时了没必要采用。104/72SOA与微服务在面对企业遗留IT系统架构的时候，SOA本身实际也是做两个重要的事情，❶是找到各个遗留系统共性的可复用的业务能力；❷其次就是在构建上层业务流程的时候通过服务组装和编排来完成。因此SOA更多的是一种架构思想，不能简单的认为是一种架构风格，更是一套软件设计的基础平台，进一步总结是：只要我们在架构设计的时候符合这个思想即是SOA。我们在谈SOA的时候一般会将SOA和ESB服务总线结合起来谈。即认为SOA即是一个类似ESB总线的进行业务系统间接口集成和统一管控的集成平台。105/72基于遗留系统已有可复用的能力，分层组装的方式来构建上层业务应用。SOA与微服务微服务架构强调的第一个重点就是原来的单体业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端webui，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适，每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。106/72SOA与微服务对于微服务实际本身又强调了几个重点，简单总结如下：拆分后的微服务从数据库，逻辑层到前端都完全独立松耦合。微服务间通过轻量HTTPAPI接口交互。微服务间以去中心化方式调用，不需要中心化总线平台。107/72如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。SOA与微服务如果从一个单体应用改造为微服务，那么微服务将通过类似服务注册中心等去中心化的方式完成集成。但是如果一个单体应用需要类似APP应用等前端访问，往往仍然需要一个统一的代理网关来对外暴露接口，这个即常说的API网关。API网关可以理解为一个轻量的ESB总线能力实现。API网关不仅仅实现了服务代理和API接口的位置透明，同时也实现了类似服务安全、限流熔断、日志、监控等关键的服务治理管控能力。108/72SOA是否过时？SOA和微服务反而不是同一个层面的两个概念。原来业务系统构建中的组件化才是和微服务对等的一个概念。在云计算不断发展演进过程中，整个IT架构也在不断地发展演进，新的技术也在层出不穷，有些老的技术过时也是常见现象。但是当前实际是很多人连SOA是什么都还没有搞清楚，就在说SOA已经过时，这种人就是典型的追热点，炒概念的人。109/72SOA是否过时？包括最近已经听到很多人在说中台过时了，阿里在拆中台了，同样，这些人连中台究竟是什么？中台思想本质在哪里都没有搞清楚就在批评中台。包括有些提供中台服务的厂商，把中台吹得天花乱坠，无所不能，结果一到了客户内部最终建设实施发现无法落地，发现原来的业务问题同样无法解决，反而引入了更加难以管理的IT复杂度。110/72ESB总线和API网关API网关本身也是一个中心化的API接口集成架构。在微服务架构体系下本身是去中心化的架构，通过服务注册中心来实现服务注册发现和消费调用，那么为何又需要使用API网关？在传统的ESB总线进行服务集成的时候我们就经常谈到一个概念就是位置透明：即需要屏蔽底层业务模块提供API接口服务地址信息，并实现多个微服务API接口的统一出口。即类似设计模式里面经常谈到的门面模式。111/72ESB总线和API网关112/72ESB总线和API网关简单来说API网关就是将所有的微服务提供的API接口服务能力全部汇聚进来，统一接入进行管理，也正是通过统一拦截，就可以通过网关实现对API接口的安全，日志，限流熔断等共性需求。如果再简单说下，通过网关实现了几个关键能力。内部的微服务对外部访问来说位置透明，外部应用只需和网关交互统一拦截接口服务，实现安全，日志，限流熔断等需求113/72ESB总线和API网关114/72ESB总线和API网关因此一个应用内部的微服务模块之间可以去中心化集成，但是这个应用需要和传统的遗留IT系统、需要和外部APP等进行接口集成的时候，往往就需要借助API网关的能力来完成。即使对于一个应用内部，只要存在类似外部APP前端需要访问后端服务接口，那么就引入了API网关，整个架构就很难说是一个完全意义上的去中心化架构。因此，简单地说微服务完全去中心化，这个说法是不成立的。115/72ESB总线和API网关新老架构并存时仍然需要ESB总线同时在微服务架构实施过程中，一个微服务应用本身还需要和传统的遗留IT系统之间集成，只要还存在这种传统的遗留IT系统，那么这种集成场景就存在，仍然需要通过类似ESB总线或轻量的SOA服务总线来完成接口集成和管控工作。我们以一个集成场景来进行说明，即企业遗留系统集成采用ESB服务总线，而对于新建设的一个微服务应用采用API网关，那么就存在两者协同和集成的过程，整体集成架构如下：116/72ESB总线和API网关117/72ESB总线和API网关可以看到，在这种集成架构下，微服务整体应用系统中所有的需要和遗留系统交互的接口全部首先接入和注册到API网关，同时API网关暴露的服务进一步集成和注册到ESB服务总线，形成两级服务集成的方式。在这种两级服务集成模式下好处包括：微服务应用体系里面的各个微服务仅仅需要暴露特定的API接口到网关和ESB内部微服务间的RestAPI交互仍然可以走注册中心，而且对外透明可以进一步使用ESB总线协议转换和适配能力，完成SOAP和Rest接口转换和适配118/72E