一文详解：如何设计出高可用的分布式架构？

　　【资讯】本文作者将与大家分享目前主流的分布式架构、分布式架构中常见理论以及如何才能设计出高可用的分布式架构。

　　在分布式架构中，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)架构解析

　　2017 年年底，非侵入式的 Service Mesh 技术慢慢走向了成熟。Service Mesh ，中文释义“服务网格”，作为服务间通信的基础设施层在系统中存在。

　　如果要用一句话来解释什么叫 Service Mesh，我们可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务间的网络调用、熔断、限流和监控。

　　我们都知道在编写应用程序时程序猿一般都无须关心 TCP/IP 这一层(比如提供 HTTP 协议的 Restful 应用)。

　　同样如果使用服务网格我们也就不需要关心服务间的那些原来是由应用程序或者其他框架实现的事情(熔断、限流、监控等)，现在只要交给 Service Mesh 就可以了。

　　服务网格架构图如下：

　　目前流行的 Service Mesh 开源软件有：Linkerd、Envoy 和 Istio。而最近 Buoyant(开源 Linkerd 的公司)又发布了基于 Kubernetes 的 Service Mesh 开源项目 Conduit。

　　关于微服务和服务网格的区别，我这样理解：微服务更注重服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信，以及和 DevOps 更好的结合等。

　　服务网格的特征：

　　应用程序间通讯的中间层

　　轻量级网络代理

　　应用程序无感知

　　解耦应用程序的重试/超时、监控、追踪和服务发现

　　分布式架构的基本理论

　　在说 CAP、BASE 理论之前，我们先要了解下分布式一致性的问题。对于不同业务的服务，我们对数据一致性的要求是不一样的。

　　例如 12306，它要求数据的严格一致性，不能把票卖给用户以后却发现没有座位了。

　　再比如银行转账， 我们通过银行转账的时候，一般都会收到一个提示：转账申请将会在 24 小时内到账。

　　实际上这个场景满足的是最终钱只要转账成功了即可，同时如果钱没汇出去还要保证资金不丢失。

　　所以说，用户在使用不同的服务的时候对数据一致性的要求是不一样的。

　　关于分布式一致性问题

　　分布式系统中要解决的一个非常重要的问题就是数据的复制。

　　在我们的日常开发经验中，相信大多数开发人员都遇过这样的问题：在做数据库读写分离的场景中，假设客户端 A 将系统中的一个值 V 由 V1 变更为 V2。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!