主流分布式系统架构分析.docxVIP

- . z 主流分布式系统架构分析 目录 TOC \o 1-3 \h \z \u 一、前言 3 二、SOA架构解析 3 三、微效劳〔Microservices〕架构解析 3 四、SOA 和微效劳架构的差异 3 五、效劳网格〔Service Mesh〕架构解析 3 六、分布式架构的根本理论 3 七、分布式架构下的高可用设计 3 八、总结 3 一、前言 本文我们来聊一聊目前主流的分布式架构和分布式架构中常见理论以及如何才能设计出高可用的分布式架构好了。分布式架构中，SOA和微效劳架构是最常见两种分布式架构，而且目前效劳网格的概念也越来越火了。那我们本文就先从这些常见架构开场。 二、SOA架构解析 ? SOA 全称是: Service Oriented Architecture，中文释义为“面向效劳的架构〞，它是一种设计理念，其中包含多个效劳，效劳之间通过相互依赖最终提供一系列完整的功能。各个效劳通常以独立的形式部署运行，效劳之间通过网络进展调用。架构图如下： ?跟 SOA 相提并论的还有一个 ESB(企业效劳总线)，简单来说 ESB 就是一根管道，用来连接各个效劳节点。ESB的存在是为了集成基于不同协议的不同效劳，ESB 做了消息的转化、解释以及路由的工作，以此来让不同的效劳互联互通; 随着我们业务的越来越复杂，会发现效劳越来越多，SOA架构下，它们的调用关系会变成如下形式： 很显然，这样不是我们所想要的，那这时候如果我们引入ESB的概念，工程调用就又会很清晰，如下： SOA所要解决的核心问题 系统间的集成 : 我们站在系统的角度来看，首先要解决各个系统间的通信问题，目的是将原先系统间散乱、无规划的网状构造，梳理成规整、可治理的星形构造，这步的实现往往需要引入一些概念和规，比方 ESB、以及技术规、效劳管理规; 这一步解决的核心问题是【有序】。 系统的效劳化 : 我们站在功能的角度，需要把业务逻辑抽象成可复用、可组装的效劳，从而通过效劳的编排实现业务的快速再生，目的是要把原先固有的业务功能抽象设计为通用的业务效劳、实现业务逻辑的快速复用;这步要解决的核心问题是【复用】。 业务的效劳化 : 我们站在企业的角度，要把企业职能抽象成可复用、可组装的效劳，就要把原先职能化的企业架构转变为效劳化的企业架构，以便进一步提升企业的对外效劳的能力。“前面两步都是从技术层面来解决系统调用、系统功能复用的问题〞。而本步骤，则是以业务驱动把一个业务单元封装成一项效劳。要解决的核心问题是【高效】。 三、微效劳〔Microservices〕架构解析 ?微效劳架构和 SOA 架构非常类似,微效劳只是 SOA 的升华，只不过微效劳架构强调的是“业务需要彻底的组件化及效劳化〞，原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用。这些小应用间通过效劳化完成交互和集成。组件表示的就是一个可以独立更换和升级的单元，就像 PC 中的 CPU、存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。假设我们把 PC 中的各个组件以效劳的方式构建，则这台 PC 只需要维护主板〔可以理解为ESB〕和一些必要的外部设备就可以。CPU、存、硬盘等都是以组件方式提供效劳，例如PC 需要调用 CPU 做计算处理，只需知道 CPU 这个组件的地址就可以了。 微效劳的特征 通过效劳实现组件化 按业务能力来划分效劳和开发团队 去中心化 根底设施自动化(devops、自动化部署) 四、SOA 和微效劳架构的差异 ?微效劳不再强调传统SOA架构里面比较重的ESB企业效劳总线，同时以 SOA 的思想进入到单个业务系统部实现真正的组件化。 ? Docker 容器技术的出现，为微效劳提供了非常便利的条件，比方更小的部署单元，每个效劳可以通过类似 Spring Boot 或者 Node 等技术独立运行。 ?还有一个点大家应该可以分析出来，SOA 注重的是系统集成，而微效劳关注的是完全别离。 五、效劳网格〔Service Mesh〕架构解析 ? 17 年年底，非侵入式的 Service Mesh 技术慢慢走向了成熟。Service Mesh ，中文释义“效劳网格〞，作为效劳间通信的根底设施层在系统中存在。如果要用一句话来解释什么叫 Service Mesh，我们可以将它比作是应用程序或者说微效劳间的 TCP/IP层，负责效劳间的网络调用、熔断、限流和监控。我们都知道在编写应用程序时程序猿一般都无须关心 TCP/IP 这一层〔比方提供 HTTP 协议的 Restful 应用〕，同样如果使用效劳网格我们也就不需要关系效劳间的那些原来是由应用程序