微服务并非Spring Cloud和Dubbo，下一代微服务是什么？
近几年，微服务技术得以迅猛普及，而以 Spring Cloud、Dubbo 为代表较为成熟的微服务开发框架，占据着市场的主流地位，它们甚至一度成为微服务的代名词。
什么是微服务
首先微服务并没有一个官方的定义，想要直接描述微服务比较困难，我们可以通过对比传统 Web 应用，来理解什么是微服务。
传统的 Web 应用核心分为业务逻辑、适配器以及 API 或通过 UI 访问的 Web 界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。
一个打车软件的架构图如下：
尽管也是遵循模块化开发，但最终它们会打包并部署为单体式应用。例如 Java 应用程序会被打包成 WAR，部署在 Tomcat 或者 Jetty 上。
这种单体应用比较适合于小项目，优点是：
- 开发简单直接，集中式管理
- 基本不会重复开发
- 功能都在本地，没有分布式的管理开销和调用开销
当然它的缺点也十分明显，特别对于互联网公司来说：
- 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断。
- 代码维护难：代码功能耦合在一起，新人不知道从何下手。
- 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长。
- 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉。
- 扩展性不够：无法满足高并发情况下的业务需求。
所以，现在主流的设计一般会采用微服务架构。其思路不是开发一个巨大的单体式应用，而是将应用分解为小的、互相连接的微服务。
一个微服务完成某个特定功能，比如乘客管理和下单管理等。每个微服务都有自己的业务逻辑和适配器。一些微服务还会提供 API 接口给其他微服务和应用客户端使用。
比如，前面描述的系统可被分解为：
每个业务逻辑都被分解为一个微服务，微服务之间通过 REST API 通信。一些微服务也会向终端用户或客户端开发 API 接口。
但通常情况下，这些客户端并不能直接访问后台微服务，而是通过 API Gateway 来传递请求。API Gateway 一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。
微服务架构的优点
微服务架构有很多重要的优点。首先，它解决了复杂性问题。它将单体应用分解为一组服务。
虽然功能总量不变，但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的 RPC 或消息驱动的 API 边界。
微服务架构强化了应用模块化的水平，而这通过单体代码库很难实现。因此，微服务开发的速度要快很多，更容易理解和维护。
其次，这种体系结构使得每个服务都可以由专注于此服务的团队独立开发。只要符合服务 API 契约，开发人员可以自由选择开发技术。
这就意味着开发人员可以采用新技术编写或重构服务，由于服务相对较小，所以这并不会对整体应用造成太大影响。
第三，微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得 CI／CD 成为可能。
最后，微服务架构使得每个服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、实例数量等约束条件即可。
比如我们可以在 EC2 计算优化实例上部署 CPU 密集型服务，在 EC2 内存优化实例上部署内存数据库服务。
微服务架构的缺点和挑战
实际上并不存在 silver bullets，微服务架构也会给我们带来新的问题和挑战。其中一个就和它的名字类似，微服务强调了服务大小，但实际上这并没有一个统一的标准。
业务逻辑应该按照什么规则划分为微服务，这本身就是一个经验工程。有些开发者主张 10-100 行代码就应该建立一个微服务。
虽然建立小型服务是微服务架构崇尚的，但要记住，微服务是达到目的的手段，而不是目标。微服务的目标是充分分解应用程序，以促进敏捷开发和持续集成部署。
微服务的另一个主要缺点是微服务的分布式特点带来的复杂性。开发人员需要基于 RPC 或者消息实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。
微服务的另一个挑战是分区的数据库体系和分布式事务。更新多个业务实体的业务交易相当普遍。这些类型的事务在单体应用中实现非常简单，因为单体应用往往只存在一个数据库。
但在微服务架构下，不同服务可能拥有不同的数据库。CAP 原理的约束，使得我们不得不放弃传统的强一致性，而转而追求最终一致性，这个对开发人员来说是一个挑战。
微服务架构对测试也带来了很大的挑战。传统的单体 Web 应用只需测试单一的 REST API 即可，而对微服务进行测试，需要启动它依赖的所有其他服务。这种复杂性不可低估。
微服务的另一大挑战是跨多个服务的更改。比如在传统单体应用中，若有 A、B、C 三个服务需要更改，A 依赖 B，B 依赖 C。我们只需更改相应的模块，然后一次性部署即可。
但是在微服务架构中，我们需要仔细规划和协调每个服务的变更部署。我们需要先更新 C，然后更新 B，最后更新 A。
部署基于微服务的应用也要复杂得多。单体应用可以简单的部署在一组相同的服务器上，然后前端使用负载均衡即可。
每个应用都有相同的基础服务地址，例如数据库和消息队列。而微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。
此外，我们还需要服务发现机制，以便服务可以发现与其通信的其他服务的地址。因此，成功部署微服务应用需要开发人员有更好地部署策略和高度自动化的水平。
以上问题和挑战可大体概括为：
- API Gateway
- 服务间调用
- 服务发现
- 服务容错
- 服务部署
- 数据调用
幸运的是，出现了很多微服务框架，可以解决以上问题。
第一代微服务框架
Spring Cloud
Spring Cloud 为开发者提供了快速构建分布式系统的通用模型的工具（包括配置管理、服务发现、熔断器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态等）。
主要项目包括：
- Spring Cloud Config：由 Git 存储库支持的集中式外部配置管理。配置资源直接映射到 Spring Environment，但是如果需要可以被非 Spring 应用程序使用。
- Spring Cloud Netflix：与各种 Netflix OSS 组件（Eureka，Hystrix，Zuul，Archaius等）集成。
- Spring Cloud Bus：用于将服务和服务实例与分布式消息传递联系起来的事件总线。用于在集群中传播状态更改（例如配置更改事件）。
- Spring Cloud for Cloudfoundry：将您的应用程序与 Pivotal Cloudfoundry 集成。提供服务发现实现，还可以轻松实现通过 SSO 和 OAuth 2 保护资源，还可以创建 Cloudfoundry 服务代理。
- Spring Cloud - Cloud Foundry Service Broker：提供构建管理一个 Cloud Foundry 中服务的服务代理的起点。
- Spring Cloud Cluster：领导选举和通用状态模型（基于 ZooKeeper，Redis，Hazelcast，Consul 的抽象和实现）。
- Spring Cloud Consul：结合 Hashicorp Consul 的服务发现和配置管理。
- Spring Cloud Security：在 Zuul 代理中为负载平衡的 OAuth 2 休眠客户端和认证头中继提供支持。
- Spring Cloud Sleuth：适用于 Spring Cloud 应用程序的分布式跟踪，与 Zipkin，HTrace 和基于日志（例如 ELK）跟踪兼容。
- Spring Cloud Data Flow：针对现代运行时的可组合微服务应用程序的云本地编排服务。易于使用的 DSL，拖放式 GUI 和 REST-API 一起简化了基于微服务的数据管道的整体编排。
- Spring Cloud Stream：轻量级事件驱动的微服务框架，可快速构建可连接到外部系统的应用程序。使用 Apache Kafka 或 RabbitMQ 在 Spring Boot 应用程序之间发送和接收消息的简单声明式模型。
- Spring Cloud Stream Application Starters：Spring Cloud 任务应用程序启动器是 Spring Boot 应用程序，可能是任何进程，包括不会永远运行的 Spring Batch 作业，并且它们在有限时间的数据处理之后结束/停止。
- Spring Cloud ZooKeeper：ZooKeeper 的服务发现和配置管理。
- Spring Cloud for Amazon Web Services：轻松集成托管的 Amazon 的 Web Services 服务。它通过使用 Spring 的 idioms 和 APIs 便捷集成 AWS 服务，例如缓存或消息 API。开发人员可以围绕托管服务，不必关心基础架构来构建应用。
- Spring Cloud Connectors：使 PaaS 应用程序在各种平台上轻松连接到后端服务，如数据库和消息代理（以前称为“Spring Cloud”的项目）。
- Spring Cloud Starters：作为基于 Spring Boot 的启动项目，降低依赖管理（在 Angel.SR2 后，不再作为独立项目）。
- Spring Cloud CLI：插件支持基于 Groovy 预言快速创建 Spring Cloud 的组件应用。
Dubbo
Dubbo 是一个阿里巴巴开源出来的一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。
其核心部分包含：
- 远程通讯：提供对多种基于长连接的 NIO 框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
- 集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
- 自动发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
但是显而易见，无论是 Dubbo 还是 Spring Cloud 都只适用于特定的应用场景和开发环境，它们的设计目的并不是为了支持通用性和多语言性。
并且它们只是 Dev 层的框架，缺少 DevOps 的整体解决方案（这正是微服务架构需要关注的）。而随之而来的便是 Service Mesh 的兴起。
下一代微服务：Service Mesh？
Service Mesh
Service Mesh 又译作“服务网格”，作为服务间通信的基础设施层。如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。
对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用）。
同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。
Service Mesh 有如下几个特点：
- 应用程序间通讯的中间层
- 轻量级网络代理
- 应用程序无感知
- 解耦应用程序的重试/超时、监控、追踪和服务发现
Service Mesh 的架构如下图所示：
Service Mesh 作为 Sidebar 运行，对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在 Service Mesh 中实现。
目前流行的 Service Mesh 开源软件有 Linkerd、Envoy 和 Istio，而最近 Buoyant（开源 Linkerd 的公司）又发布了基于 Kubernetes 的 Service Mesh 开源项目 Conduit。
Linkerd
Linkerd 是开源网络代理，设计为以服务网格部署：用于管理，控制和监控应用程序内的服务与服务间通讯的专用层。
Linkerd 旨在解决 Twitter、Yahoo、Google 和 Microsoft 等公司运营大型生产系统时发现的问题。
根据经验，最复杂，令人惊奇和紧急行为的来源通常不是服务本身，而是服务之间的通讯。Linkerd 解决了这些问题，不仅仅是控制通讯机制，而是在其上提供一个抽象层。
它的主要特性有：
- 负载平衡：Linkerd 提供了多种负载均衡算法，它们使用实时性能指标来分配负载并减少整个应用程序的尾部延迟。
- 熔断：Linkerd 包含自动熔断，将停止将流量发送到被认为不健康的实例，从而使他们有机会恢复并避免连锁反应故障。
- 服务发现：Linkerd 与各种服务发现后端集成，通过删除特定的(ad-hoc)服务发现实现来帮助您降低代码的复杂性。
- 动态请求路由：Linkerd 启用动态请求路由和重新路由，允许您使用最少量的配置来设置分段服务（staging service），金丝雀（canaries），蓝绿部署（blue-green deploy），跨 DC 故障切换和黑暗流量（dark traffic）。
- 重试次数和截止日期：Linkerd 可以在某些故障时自动重试请求，并且可以在指定的时间段之后让请求超时。
- TLS：Linkerd 可以配置为使用 TLS 发送和接收请求，您可以使用它来加密跨主机边界的通信，而不用修改现有的应用程序代码。
- HTTP 代理集成：Linkerd 可以作为 HTTP 代理，几乎所有现代 HTTP 客户端都广泛支持，使其易于集成到现有应用程序中。
- 透明代理：您可以在主机上使用 iptables 规则，设置通过 Linkerd 的透明代理。
- gRPC：Linkerd 支持 HTTP/2 和 TLS，允许它路由 gRPC 请求，支持高级 RPC 机制，如双向流，流程控制和结构化数据负载。
- 分布式跟踪：Linkerd 支持分布式跟踪和度量仪器，可以提供跨越所有服务的统一的可观察性。
- 仪器仪表：Linkerd 支持分布式跟踪和度量仪器，可以提供跨越所有服务的统一的可观察性。
Envoy
Envoy 是一个面向服务架构的 L7 代理和通信总线而设计的，这个项目诞生是出于以下目标：
对于应用程序而言，网络应该是透明的，当发生网络和应用程序故障时，能够很容易定位出问题的根源。
Envoy 可提供以下特性：
- 外置进程架构：可与任何语言开发的应用一起工作；可快速升级。
- 基于新 C++11 编码：能够提供高效的性能。
- L3/L4 过滤器：核心是一个 L3/L4 网络代理，能够作为一个可编程过滤器实现不同 TCP 代理任务，插入到主服务当中。通过编写过滤器来支持各种任务，如原始 TCP 代理、HTTP 代理、TLS 客户端证书身份验证等。
- HTTP L7 过滤器：支持一个额外的 HTTP L7 过滤层。HTTP 过滤器作为一个插件，插入到 HTTP 链接管理子系统中，从而执行不同的任务，如缓冲，速率限制，路由/转发，嗅探 Amazon 的 DynamoDB 等等。
- 支持 HTTP/2：在 HTTP 模式下，支持 HTTP/1.1、HTTP/2，并且支持 HTTP/1.1、HTTP/2 双向代理。这意味着 HTTP/1.1 和 HTTP/2，在客户机和目标服务器的任何组合都可以桥接。
- HTTP L7 路由：在 HTTP 模式下运行时，支持根据 content type、runtime values 等，基于 path 的路由和重定向。可用于服务的前端／边缘代理。
- 支持 gRPC：gRPC 是一个来自谷歌的 RPC 框架，使用 HTTP/2 作为底层的多路传输。HTTP/2 承载的 gRPC 请求和应答，都可以使用 Envoy 的路由和 LB 能力。
- 支持 MongoDB L7：支持获取统计和连接记录等信息。
- 支持 DynamoDB L7：支持获取统计和连接等信息。
- 服务发现：支持多种服务发现方法，包括异步 DNS 解析和通过 REST 请求服务发现服务。
- 健康检查：含有一个健康检查子系统，可以对上游服务集群进行主动的健康检查。也支持被动健康检查。
- 高级 LB：包括自动重试、断路器，全局限速，阻隔请求，异常检测。未来还计划支持请求速率控制。
- 前端代理：可作为前端代理，包括 TLS、HTTP/1.1、HTTP/2，以及 HTTP L7 路由。
- 极好的可观察性：对所有子系统，提供了可靠的统计能力。目前支持 statsd 以及兼容的统计库。还可以通过管理端口查看统计信息，还支持第三方的分布式跟踪机制。
- 动态配置：提供分层的动态配置 API，用户可以使用这些 API 构建复杂的集中管理部署。
Istio
Istio 是一个用来连接、管理和保护微服务的开放平台。Istio 提供一种简单的方式来建立已部署服务网络，具备负载均衡、服务间认证、监控等功能，而不需要改动任何服务代码。
想要为服务增加对 Istio 的支持，您只需要在环境中部署一个特殊的边车（sidecar），使用 Istio 控制面板功能配置和管理代理，拦截微服务之间的所有网络通信。
Istio 目前仅支持在 Kubernetes 上的服务部署，但未来版本中将支持其他环境。
Istio 提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。
它在服务网络中统一提供了许多关键功能：
- 流量管理：控制服务之间的流量和 API 调用的流向，使得调用更可靠，并使网络在恶劣情况下更加健壮。
- 可观察性：了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力。
- 策略执行：将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。
- 服务身份和安全：为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。
Istio 服务网格逻辑上分为数据面板和控制面板：
- 数据面板由一组智能代理（Envoy）组成，代理部署为边车，调解和控制微服务之间所有的网络通信。
- 控制面板负责管理和配置代理来路由流量，以及在运行时执行策略。
下图显示了构成每个面板的不同组件：
Conduit
Conduit 是为 Kubernetes 设计的一个超轻型服务网格服务，它可透明地管理在 Kubernetes 上运行的服务的运行时通信，使得它们更安全可靠。Conduit 提供了可见性、可靠性和安全性的功能，而无需更改代码。
Conduit service mesh 也是由数据面板和控制面板组成。数据面板承载应用实际的网络流量。控制面板驱动数据面板，并对外提供北向接口。
对比
Linkerd 和 Envoy 比较相似，都是一种面向服务通信的网络代理，均可实现诸如服务发现、请求路由、负载均衡等功能。
它们的设计目标就是为了解决服务之间的通信问题，使得应用对服务通信无感知，这也是 Service Mesh 的核心理念。
Linkerd 和 Envoy 像是分布式的 Sidebar，多个类似 Linkerd 和 Envoy 的 proxy 互相连接，就组成了 Service Mesh。
而 Istio 则是站在了一个更高的角度，它将 Service Mesh 分为了 Data Plane 和 Control Plane。
Data Plane 负责微服务间的所有网络通信，而 Control Plane 负责管理 Data Plane Proxy：
并且 Istio 天生的支持 Kubernetes，这也弥合了应用调度框架与 Service Mesh 之间的空隙。
关于 Conduit 的资料较少，从官方介绍看它的定位和功能与 Istio 类似。
Kubernetes + Service Mesh = 完整的微服务框架
Kubernetes 已经成为了容器调度编排的事实标准，而容器正好可以作为微服务的最小工作单元，从而发挥微服务架构的最大优势。
所以我认为未来微服务架构会围绕 Kubernetes 展开。而 Istio 和 Conduit 这类 Service Mesh 天生就是为了 Kubernetes 设计，它们的出现补足了 Kubernetes 在微服务间服务通讯上的短板。
虽然 Dubbo、Spring Cloud 等都是成熟的微服务框架，但是它们或多或少都会和具体语言或应用场景绑定，并只解决了微服务 Dev 层面的问题。
若想解决 Ops 问题，它们还需和诸如 Cloud Foundry、Mesos、Docker Swarm 或 Kubernetes 这类资源调度框架做结合：
但是这种结合又由于初始设计和生态，有很多适用性问题需要解决。
Kubernetes 则不同，它本身就是一个和开发语言无关的、通用的容器管理平台，它可以支持运行云原生和传统的容器化应用。
并且它覆盖了微服务的 Dev 和 Ops 阶段，结合 Service Mesh，它可以为用户提供完整端到端的微服务体验。
所以我认为，未来的微服务架构和技术栈可能是如下形式：
多云平台为微服务提供了资源能力（计算、存储和网络等），容器作为最小工作单元被 Kubernetes 调度和编排，Service Mesh 管理微服务的服务通信，最后通过 API Gateway 向外暴露微服务的业务接口。