猜测未来微服务架构
微服務(wù)架構(gòu)
微服務(wù)的概念在2014年3月由Martin Fowler首次提出。
微服務(wù)架構(gòu)解決的核心問(wèn)題及其相應(yīng)的開(kāi)源組件如下所示：
- RPC框架 (Service-to-service calls)
- Spring Boot/Spring MVC
- Dubbo
- gRPC
- thrift
- 服務(wù)注冊(cè)和發(fā)現(xiàn) (Service registration and discovery)
- 注冊(cè)中心
- Eureka: 在 Netflix 經(jīng)過(guò)大規(guī)模生產(chǎn)驗(yàn)證，支持跨數(shù)據(jù)中心。
- Consul: 天然支持跨數(shù)據(jù)中心，還支持 KV 模型存儲(chǔ)和靈活健康檢查能力
- ZooKeeper
- Redis
- Nacos
- 注冊(cè)中心
- 負(fù)載均衡 (Load balancing)
- Ribbon/Feign
- Nginx
- HAProxy
- RPC client
- 容錯(cuò)限流 (Circuit Breakers)
- Hystrix
- Nginx/Kong + RateLimit
- Sentinel
- 認(rèn)證授權(quán) (Security)
- Spring Security/Spring Cloud Security
- OAuth
- OpenID connect
- 服務(wù)網(wǎng)關(guān)和路由 (Routing)
- Zuul: 在 Netflix 經(jīng)過(guò)大規(guī)模生產(chǎn)驗(yàn)證，支持靈活的動(dòng)態(tài)過(guò)濾器腳本機(jī)制，異步性能不足（基于 Netty 的異步 Zuul 遲遲未能推出正式版）
- Kong: Nginx/OpenResty 的 API 網(wǎng)關(guān)。
- 配置中心 (Distributed/versioned configuration)
- Spring Cloud Config
- Apollo@攜程
- Nacos
- 監(jiān)控告警
- 日志監(jiān)控 (Logging)
- ELK
- 調(diào)用鏈監(jiān)控 (Tracing)
- CAT@點(diǎn)評(píng)
- Zipkin@Twitter
- Pinpoint@Naver
- Metrics 監(jiān)控 (stats, metrics)
- 存儲(chǔ) (TSDB)
- OpenTSDB(HBase) + Argus，KariosDB(Cassandra) + ZMon
- InfluxDB
- Prometheus
- 告警
- Argus 是 Salesforce 開(kāi)源的基于 OpenTSDB 的統(tǒng)一監(jiān)控告警平臺(tái)，支持豐富的告警函數(shù)和靈活的告警配置。
- ZMon 后臺(tái)采用 KairosDB 存儲(chǔ)，如果企業(yè)已經(jīng)采用 KariosDB 作為時(shí)間序列數(shù)據(jù)庫(kù)
- 報(bào)表
- Grafana 是 Metrics 報(bào)表展示的社區(qū)標(biāo)配
- 存儲(chǔ) (TSDB)
- 健康檢查
- 告警通知
- Elastalert 是 Yelp 開(kāi)源的針對(duì) ELK 的告警通知模塊
- 日志監(jiān)控 (Logging)
- 任務(wù)調(diào)度
- Quartz、elastic-job、xxl-job
- oozie?: Hadoop Job Scheduling
- Azkaban@Linkedin?: Hadoop Job Scheduling
- luigi@Spotify?: One major difference is that Luigi is not just built specifically for Hadoop, and it’s easy to extend it with other kinds of tasks.
- Airflow@Airbnb、Maat@阿里巴巴?可惜沒(méi)有開(kāi)源 : General Purpose Batch Processing
- Conductor@Netflix?: Microservice orchestration
- argo?: Open source Kubernetes native workflows, events, CI and CD.
- 事件驅(qū)動(dòng)
- Spring Cloud Stream
- 其它
- Global locks
- Leadership election and cluster state
- 部署微服務(wù) (CICD & CNCF)
- CICD
- A/B rollout
- dark launches
- auto scale
- docker
- Cloud Foundry
- Kubernetes
- Mesos
業(yè)界主流微服務(wù)解決方案
1、Netflix
- Eureka?for service discovery
- Archaius?for distributed configuration
- Ribbon?for resilient and intelligent inter-process and service communication
- Hystrix?for latency and fault tolerance at run-time
- Prana?as a sidecar for non-JVM based services.
- Zuul?(which integrates Hystrix, Eureka, and Ribbon as part of its IPC capabilities) provides dyamically scriptable proxying at the edge of the cloud deployment.
- Fenzo?as a scheduler Java library for Apache Mesos frameworks that supports plugins for scheduling optimizations and facilitates cluster autoscaling.
2、Spring Cloud: Tools for building common patterns in distributed systems with Spring.
Spring Cloud為開(kāi)發(fā)者提供了快速構(gòu)建分布式系統(tǒng)的通用模型的工具（包括配置管理、服務(wù)發(fā)現(xiàn)、熔斷器、智能路由、微代理、控制總線、一次性令牌、全局鎖、領(lǐng)導(dǎo)選舉、分布式會(huì)話、集群狀態(tài)等）。 主要項(xiàng)目包括：
- Spring Cloud Config：由Git存儲(chǔ)庫(kù)支持的集中式外部配置管理。配置資源直接映射到Spring Environment，但是如果需要可以被非Spring應(yīng)用程序使用。
- Spring Cloud Netflix：與各種Netflix OSS組件（Eureka，Hystrix，Zuul，Archaius等）集成。
- Spring Cloud Bus：用于將服務(wù)和服務(wù)實(shí)例與分布式消息傳遞聯(lián)系起來(lái)的事件總線。用于在集群中傳播狀態(tài)更改（例如配置更改事件）。
- Spring Cloud for Cloudfoundry：將您的應(yīng)用程序與Pivotal Cloudfoundry集成。提供服務(wù)發(fā)現(xiàn)實(shí)現(xiàn)，還可以輕松實(shí)現(xiàn)通過(guò) SSO 和 OAuth 2 保護(hù)資源，還可以創(chuàng)建Cloudfoundry服務(wù)代理。
- Spring Cloud - Cloud Foundry Service Broker：提供構(gòu)建管理一個(gè)Cloud Foundry中服務(wù)的服務(wù)代理的起點(diǎn)。
- Spring Cloud Cluster：領(lǐng)導(dǎo)選舉和通用狀態(tài)模型（基于ZooKeeper，Redis，Hazelcast，Consul的抽象和實(shí)現(xiàn)）。
- Spring Cloud Consul：結(jié)合Hashicorp Consul的服務(wù)發(fā)現(xiàn)和配置管理
- Spring Cloud Security：在Zuul代理中為負(fù)載平衡的OAuth 2休眠客戶(hù)端和認(rèn)證頭中繼提供支持。
- Spring Cloud Sleuth：適用于Spring Cloud應(yīng)用程序的分布式跟蹤，與Zipkin，HTrace和基于日志（例如ELK）跟蹤兼容。
- Spring Cloud Data Flow：針對(duì)現(xiàn)代運(yùn)行時(shí)的可組合微服務(wù)應(yīng)用程序的云本地編排服務(wù)。易于使用的DSL，拖放式GUI和REST-API一起簡(jiǎn)化了基于微服務(wù)的數(shù)據(jù)管道的整體編排。
- Spring Cloud Stream：輕量級(jí)事件驅(qū)動(dòng)的微服務(wù)框架，可快速構(gòu)建可連接到外部系統(tǒng)的應(yīng)用程序。使用Apache Kafka或RabbitMQ在Spring Boot應(yīng)用程序之間發(fā)送和接收消息的簡(jiǎn)單聲明式模型。
- Spring Cloud Stream Application Starters：Spring Cloud任務(wù)應(yīng)用程序啟動(dòng)器是Spring Boot應(yīng)用程序，可能是任何進(jìn)程，包括不會(huì)永遠(yuǎn)運(yùn)行的Spring Batch作業(yè)，并且它們?cè)谟邢迺r(shí)間的數(shù)據(jù)處理之后結(jié)束/停止。
- Spring Cloud ZooKeeper：ZooKeeper的服務(wù)發(fā)現(xiàn)和配置管理。
- Spring Cloud for Amazon Web Services：輕松集成托管的Amazon的Web Services服務(wù)。它通過(guò)使用Spring的idioms和APIs便捷集成AWS服務(wù)，例如緩存或消息API。開(kāi)發(fā)人員可以圍繞托管服務(wù)，不必關(guān)心基礎(chǔ)架構(gòu)來(lái)構(gòu)建應(yīng)用。
- Spring Cloud Connectors：使PaaS應(yīng)用程序在各種平臺(tái)上輕松連接到后端服務(wù)，如數(shù)據(jù)庫(kù)和消息代理（以前稱(chēng)為“Spring Cloud”的項(xiàng)目）。
- Spring Cloud Starters：作為基于Spring Boot的啟動(dòng)項(xiàng)目，降低依賴(lài)管理（在Angel.SR2后，不在作為獨(dú)立項(xiàng)目）。
- Spring Cloud CLI：插件支持基于Groovy預(yù)言快速創(chuàng)建Spring Cloud的組件應(yīng)用。
3、spring cloud alibaba: Spring Cloud Alibaba provides a one-stop solution for application development for the distributed solutions of Alibaba middleware.
Spring Cloud for Alibaba，它是由一些阿里巴巴的開(kāi)源組件和云產(chǎn)品組成的。這個(gè)項(xiàng)目的目的是為了讓大家所熟知的 Spring 框架，其優(yōu)秀的設(shè)計(jì)模式和抽象理念，以給使用阿里巴巴產(chǎn)品的 Java 開(kāi)發(fā)者帶來(lái)使用 Spring Boot 和 Spring Cloud 的更多便利。
其中阿里巴巴開(kāi)源組件的命名前綴為spring-cloud-alibaba，提供了如下特性：
- 服務(wù)注冊(cè)與發(fā)現(xiàn) : 適配 Spring Cloud 服務(wù)注冊(cè)與發(fā)現(xiàn)標(biāo)準(zhǔn)，默認(rèn)集成了 Ribbon 的支持。
- 分布式配置管理：支持分布式系統(tǒng)中的外部化配置，配置更改時(shí)自動(dòng)刷新。
- 消息驅(qū)動(dòng)能力：基于 Spring Cloud Stream 為微服務(wù)應(yīng)用構(gòu)建消息驅(qū)動(dòng)能力。
- 服務(wù)限流降級(jí) : 默認(rèn)支持 Servlet、Feign、RestTemplate、Dubbo 和 RocketMQ 限流降級(jí)功能的接入，可以在運(yùn)行時(shí)通過(guò)控制臺(tái)實(shí)時(shí)修改限流降級(jí)規(guī)則，還支持查看限流降級(jí) Metrics 監(jiān)控。
阿里云的產(chǎn)品組件的命名前綴為 spring-cloud-alicloud ，提供了如下特性：
- 應(yīng)用配置管理 : 阿里云配置管理服務(wù)ACM，加強(qiáng)了安全的配置管理，并且還包含了完整的推送軌跡查詢(xún)。
- 對(duì)象存儲(chǔ)服務(wù) : 阿里云提供的海量、安全、低成本、高可靠的云存儲(chǔ)服務(wù)。支持在任何應(yīng)用、任何時(shí)間、任何地點(diǎn)存儲(chǔ)和訪問(wèn)任意類(lèi)型的數(shù)據(jù)。
- 分布式任務(wù)調(diào)度 : 提供秒級(jí)、精準(zhǔn)、高可靠、高可用的定時(shí)（基于 Cron 表達(dá)式）任務(wù)調(diào)度服務(wù)。同時(shí)提供分布式的任務(wù)執(zhí)行模型，如網(wǎng)格任務(wù)。網(wǎng)格任務(wù)支持海量子任務(wù)均勻分配到所有 Worker（schedulerx-client）上執(zhí)行。
下面是使用到的一些組件:
- Sentinel?: 把流量作為切入點(diǎn)，從流量控制、熔斷降級(jí)、系統(tǒng)負(fù)載保護(hù)等多個(gè)維度保護(hù)服務(wù)的穩(wěn)定性。
- Nacos?: 一個(gè)更易于構(gòu)建云原生應(yīng)用的動(dòng)態(tài)服務(wù)發(fā)現(xiàn)、配置管理和服務(wù)管理平臺(tái)。
- RocketMQ?: 一款開(kāi)源的分布式消息系統(tǒng)，基于高可用分布式集群技術(shù)，提供低延時(shí)的、高可靠的消息發(fā)布與訂閱服務(wù)。
- Alibaba Cloud ACM?: 一款在分布式架構(gòu)環(huán)境中對(duì)應(yīng)用配置進(jìn)行集中管理和推送的應(yīng)用配置中心產(chǎn)品。
- Alibaba Cloud OSS?: 阿里云對(duì)象存儲(chǔ)服務(wù)（Object Storage Service，簡(jiǎn)稱(chēng) OSS），是阿里云提供的海量、安全、低成本、高可靠的云存儲(chǔ)服務(wù)。您可以在任何應(yīng)用、任何時(shí)間、任何地點(diǎn)存儲(chǔ)和訪問(wèn)任意類(lèi)型的數(shù)據(jù)。
- Alibaba Cloud SchedulerX?: 阿里中間件團(tuán)隊(duì)開(kāi)發(fā)的一款分布式任務(wù)調(diào)度產(chǎn)品，提供秒級(jí)、精準(zhǔn)、高可靠、高可用的定時(shí)（基于 Cron 表達(dá)式）任務(wù)調(diào)度服務(wù)。
但是顯然，這個(gè)并不是一個(gè)完全的開(kāi)源項(xiàng)目，因?yàn)榘⒗镌频姆?wù)是要收費(fèi)的。
4、Service Mesh
微服務(wù)的概念在2014年3月由Martin Fowler首次提出，而Service Mesh的概念則是在2016年左右提出，Service Mesh至今也經(jīng)歷了第二代的發(fā)展。
Service Mesh又譯作“服務(wù)網(wǎng)格”，作為服務(wù)間通信的基礎(chǔ)設(shè)施層。如果用一句話來(lái)解釋什么是Service Mesh，可以將它比作是應(yīng)用程序或者說(shuō)微服務(wù)間的TCP/IP，負(fù)責(zé)服務(wù)之間的網(wǎng)絡(luò)調(diào)用、限流、熔斷和監(jiān)控。對(duì)于編寫(xiě)應(yīng)用程序來(lái)說(shuō)一般無(wú)須關(guān)心TCP/IP這一層（比如通過(guò) HTTP 協(xié)議的 RESTful 應(yīng)用），同樣使用Service Mesh也就無(wú)須關(guān)系服務(wù)之間的那些原來(lái)是通過(guò)應(yīng)用程序或者其他框架實(shí)現(xiàn)的事情，比如Spring Cloud、OSS，現(xiàn)在只要交給Service Mesh就可以了。
Service Mesh有如下幾個(gè)特點(diǎn)：
- 應(yīng)用程序間通訊的中間層
- 輕量級(jí)網(wǎng)絡(luò)代理
- 應(yīng)用程序無(wú)感知
- 解耦應(yīng)用程序的重試/超時(shí)、監(jiān)控、追蹤和服務(wù)發(fā)現(xiàn)
Service Mesh的架構(gòu)如下圖所示：
Service Mesh作為Sidebar運(yùn)行，對(duì)應(yīng)用程序來(lái)說(shuō)是透明，所有應(yīng)用程序間的流量都會(huì)通過(guò)它，所以對(duì)應(yīng)用程序流量的控制都可以在Service Mesh中實(shí)現(xiàn)。
目前流行的開(kāi)源 Service Mesh 框架有：
- Linkerd
- Envoy
- Istio
- Conduit
1、Linkerd 1.x
Linkerd 1.x 基于Twitter的Fingle，使用Scala編寫(xiě)，是業(yè)界第一個(gè)開(kāi)源的Service Mesh方案，在長(zhǎng)期的實(shí)際生產(chǎn)環(huán)境中獲得驗(yàn)證。
它的主要特性有：
- 負(fù)載均衡：Linkerd提供了多種負(fù)載均衡算法，它們使用實(shí)時(shí)性能指標(biāo)來(lái)分配負(fù)載并減少整個(gè)應(yīng)用程序的尾部延遲。
- 熔斷：Linkerd包含自動(dòng)熔斷，將停止將流量發(fā)送到被認(rèn)為不健康的實(shí)例，從而使他們有機(jī)會(huì)恢復(fù)并避免連鎖反應(yīng)故障。
- 服務(wù)發(fā)現(xiàn)：Linkerd 與各種服務(wù)發(fā)現(xiàn)后端集成，通過(guò)刪除特定的(ad-hoc)服務(wù)發(fā)現(xiàn)實(shí)現(xiàn)來(lái)幫助您降低代碼的復(fù)雜性。
- 動(dòng)態(tài)請(qǐng)求路由：Linkerd 啟用動(dòng)態(tài)請(qǐng)求路由和重新路由，允許您使用最少量的配置來(lái)設(shè)置分段服務(wù)（staging service），金絲雀（canaries），藍(lán)綠部署（blue-green deploy），跨DC故障切換和黑暗流量（dark traffic）。
- 重試次數(shù)和截止日期：Linkerd可以在某些故障時(shí)自動(dòng)重試請(qǐng)求，并且可以在指定的時(shí)間段之后讓請(qǐng)求超時(shí)。
- TLS：Linkerd可以配置為使用TLS發(fā)送和接收請(qǐng)求，您可以使用它來(lái)加密跨主機(jī)邊界的通信，而不用修改現(xiàn)有的應(yīng)用程序代碼。
- HTTP代理集成：Linkerd可以作為HTTP代理，幾乎所有現(xiàn)代HTTP客戶(hù)端都廣泛支持，使其易于集成到現(xiàn)有應(yīng)用程序中。
- 透明代理：您可以在主機(jī)上使用iptables規(guī)則，設(shè)置通過(guò)Linkerd的透明代理。
- gRPC：Linkerd支持HTTP/2和TLS，允許它路由gRPC請(qǐng)求，支持高級(jí)RPC機(jī)制，如雙向流，流程控制和結(jié)構(gòu)化數(shù)據(jù)負(fù)載。
- 分布式跟蹤：Linkerd支持分布式跟蹤和度量?jī)x器，可以提供跨越所有服務(wù)的統(tǒng)一的可觀察性。
- 儀器儀表：Linkerd支持分布式跟蹤和度量?jī)x器，可以提供跨越所有服務(wù)的統(tǒng)一的可觀察性。
說(shuō)明：Conduit 后面合并到 Linkerd 2.0，因此本質(zhì)上 Linkerd 2.0 = Conduit。
2、Envoy
Envoy底層基于C++，性能上優(yōu)于使用Scala的Linkerd。同時(shí)，Envoy社區(qū)成熟度較高，商用穩(wěn)定版本面世時(shí)間也較長(zhǎng)。
Envoy是一個(gè)面向服務(wù)架構(gòu)的L7代理和通信總線而設(shè)計(jì)的，這個(gè)項(xiàng)目誕生是出于以下目標(biāo)：
對(duì)于應(yīng)用程序而言，網(wǎng)絡(luò)應(yīng)該是透明的，當(dāng)發(fā)生網(wǎng)絡(luò)和應(yīng)用程序故障時(shí)，能夠很容易定位出問(wèn)題的根源。
Envoy可提供以下特性：
- 外置進(jìn)程架構(gòu)：可與任何語(yǔ)言開(kāi)發(fā)的應(yīng)用一起工作；可快速升級(jí)。
- 基于新C++11編碼：能夠提供高效的性能。
- L3/L4過(guò)濾器：核心是一個(gè)L3/L4網(wǎng)絡(luò)代理，能夠作為一個(gè)可編程過(guò)濾器實(shí)現(xiàn)不同TCP代理任務(wù)，插入到主服務(wù)當(dāng)中。通過(guò)編寫(xiě)過(guò)濾器來(lái)支持各種任務(wù)，如原始TCP代理、HTTP代理、TLS客戶(hù)端證書(shū)身份驗(yàn)證等。
- HTTP L7過(guò)濾器：支持一個(gè)額外的HTTP L7過(guò)濾層。HTTP過(guò)濾器作為一個(gè)插件，插入到HTTP鏈接管理子系統(tǒng)中，從而執(zhí)行不同的任務(wù)，如緩沖，速率限制，路由/轉(zhuǎn)發(fā)，嗅探Amazon的DynamoDB等等。
- 支持HTTP/2：在HTTP模式下，支持HTTP/1.1、HTTP/2，并且支持HTTP/1.1、HTTP/2雙向代理。這意味著HTTP/1.1和HTTP/2，在客戶(hù)機(jī)和目標(biāo)服務(wù)器的任何組合都可以橋接。
- HTTP L7路由：在HTTP模式下運(yùn)行時(shí)，支持根據(jù)content type、runtime values等，基于path的路由和重定向。可用于服務(wù)的前端／邊緣代理。
- 支持gRPC：gRPC是一個(gè)來(lái)自谷歌的RPC框架，使用HTTP/2作為底層的多路傳輸。HTTP/2承載的gRPC請(qǐng)求和應(yīng)答，都可以使用Envoy的路由和LB能力。
- 支持MongoDB L7：支持獲取統(tǒng)計(jì)和連接記錄等信息。
- 支持DynamoDB L7：支持獲取統(tǒng)計(jì)和連接等信息。
- 服務(wù)發(fā)現(xiàn)：支持多種服務(wù)發(fā)現(xiàn)方法，包括異步DNS解析和通過(guò)REST請(qǐng)求服務(wù)發(fā)現(xiàn)服務(wù)。
- 健康檢查：含有一個(gè)健康檢查子系統(tǒng)，可以對(duì)上游服務(wù)集群進(jìn)行主動(dòng)的健康檢查。也支持被動(dòng)健康檢查。
- 高級(jí)LB：包括自動(dòng)重試、斷路器，全局限速，阻隔請(qǐng)求，異常檢測(cè)。未來(lái)還計(jì)劃支持請(qǐng)求速率控制。
- 前端代理：可作為前端代理，包括TLS、HTTP/1.1、HTTP/2，以及HTTP L7路由。
- 極好的可觀察性：對(duì)所有子系統(tǒng)，提供了可靠的統(tǒng)計(jì)能力。目前支持statsd以及兼容的統(tǒng)計(jì)庫(kù)。還可以通過(guò)管理端口查看統(tǒng)計(jì)信息，還支持 第三方的分布式跟蹤機(jī)制。
- 動(dòng)態(tài)配置：提供分層的動(dòng)態(tài)配置API，用戶(hù)可以使用這些API構(gòu)建復(fù)雜的集中管理部署。
3、Istio
Istio是Google、IBM和Lyft合作的開(kāi)源項(xiàng)目，是目前最主流的Service Mesh方案，也是事實(shí)上的第二代Service Mesh標(biāo)準(zhǔn)。在Istio中，直接把Envoy作為Sidecar。除了Sidecar，Istio中的控制面組件都是使用Go語(yǔ)言編寫(xiě)。
Istio在服務(wù)網(wǎng)絡(luò)中主要提供了以下關(guān)鍵功能：
- 流量管理：控制服務(wù)之間的流量和API調(diào)用的流向，使得調(diào)用更可靠，并使網(wǎng)絡(luò)在惡劣情況下更加健壯。
- 可觀察性：了解服務(wù)之間的依賴(lài)關(guān)系，以及它們之間流量的本質(zhì)和流向，從而提供快速識(shí)別問(wèn)題的能力。
- 策略執(zhí)行：將組織策略應(yīng)用于服務(wù)之間的互動(dòng)，確保訪問(wèn)策略得以執(zhí)行，資源在消費(fèi)者之間良好分配。策略的更改是通過(guò)配置網(wǎng)格而不是修改應(yīng)用程序代碼。
- 服務(wù)身份和安全：為網(wǎng)格中的服務(wù)提供可驗(yàn)證身份，并提供保護(hù)服務(wù)流量的能力，使其可以在不同可信度的網(wǎng)絡(luò)上流轉(zhuǎn)。
- 平臺(tái)支持：Istio旨在在各種環(huán)境中運(yùn)行，包括跨云、Kubernetes、Mesos等。最初專(zhuān)注于Kubernetes，但很快將支持其他環(huán)境。
- 集成和定制：策略執(zhí)行組件可以擴(kuò)展和定制，以便與現(xiàn)有的ACL、日志、監(jiān)控、配額、審核等解決方案集成。
Istio服務(wù)網(wǎng)格邏輯上分為數(shù)據(jù)面板和控制面板：
- 數(shù)據(jù)面板由一組智能代理（Envoy）組成，代理部署為邊車(chē) (Sidecar)，調(diào)解和控制微服務(wù)之間所有的網(wǎng)絡(luò)通信。
- 控制面板負(fù)責(zé)管理和配置代理來(lái)路由流量，以及在運(yùn)行時(shí)執(zhí)行策略。
下圖為Istio的架構(gòu)設(shè)計(jì)圖，主要包括了Envoy、Pilot、Mixer和Istio-Auth等。
- Envoy: 扮演Sidecar的功能，協(xié)調(diào)服務(wù)網(wǎng)格中所有服務(wù)的出入站流量，并提供服務(wù)發(fā)現(xiàn)、負(fù)載均衡、限流熔斷等能力，還可以收集與流量相關(guān)的性能指標(biāo)。
- Pilot: 負(fù)責(zé)部署在Service Mesh中的Envoy實(shí)例的生命周期管理。本質(zhì)上是負(fù)責(zé)流量管理和控制，將流量和基礎(chǔ)設(shè)施擴(kuò)展解耦，這是Istio的核心。可以把Pilot看做是管理Sidecar的Sidecar, 但是這個(gè)特殊的Sidacar并不承載任何業(yè)務(wù)流量。Pilot讓運(yùn)維人員通過(guò)Pilot指定它們希望流量遵循什么規(guī)則，而不是哪些特定的pod/VM應(yīng)該接收流量。有了Pilot這個(gè)組件，我們可以非常容易的實(shí)現(xiàn) A/B 測(cè)試和金絲雀Canary測(cè)試。
- Mixer: Mixer在應(yīng)用程序代碼和基礎(chǔ)架構(gòu)后端之間提供通用中介層。它的設(shè)計(jì)將策略決策移出應(yīng)用層，用運(yùn)維人員能夠控制的配置取而代之。應(yīng)用程序代碼不再將應(yīng)用程序代碼與特定后端集成在一起，而是與Mixer進(jìn)行相當(dāng)簡(jiǎn)單的集成，然后Mixer負(fù)責(zé)與后端系統(tǒng)連接。Mixer可以認(rèn)為是其他后端基礎(chǔ)設(shè)施（如數(shù)據(jù)庫(kù)、監(jiān)控、日志、配額等）的Sidecar Proxy。
- Istio-Auth: 提供強(qiáng)大的服務(wù)間認(rèn)證和終端用戶(hù)認(rèn)證，使用交互TLS，內(nèi)置身份和證書(shū)管理。可以升級(jí)服務(wù)網(wǎng)格中的未加密流量，并為運(yùn)維人員提供基于服務(wù)身份而不是網(wǎng)絡(luò)控制來(lái)執(zhí)行策略的能力。Istio的未來(lái)版本將增加細(xì)粒度的訪問(wèn)控制和審計(jì)，以使用各種訪問(wèn)控制機(jī)制（包括基于屬性和角色的訪問(wèn)控制以及授權(quán)鉤子）來(lái)控制和監(jiān)視訪問(wèn)服務(wù)、API或資源的訪問(wèn)者。
4、Conduit
Conduit 是開(kāi)源 Linkerd 的公司 Buoyant 基于 Kubernetes 設(shè)計(jì)的一個(gè)超輕型服務(wù)網(wǎng)格服務(wù)。它可透明地管理在Kubernetes上運(yùn)行的服務(wù)的運(yùn)行時(shí)通信，使得它們更安全可靠。Conduit提供了可見(jiàn)性、可靠性和安全性的功能，而無(wú)需更改代碼。
Conduit各方面的設(shè)計(jì)理念與Istio非常類(lèi)似，作者使用Rust語(yǔ)言重新編寫(xiě)了Sidecar, 叫做Conduit Data Plane, 控制面則由Go語(yǔ)言編寫(xiě)的Conduit Control Plane接管。從Conduit的架構(gòu)看，作者號(hào)稱(chēng)Conduit吸取了很多Linkerd的教訓(xùn)，比Linkerd更快、更輕、更簡(jiǎn)單，控制面功能更強(qiáng)。與Istio比較，Conduit的架構(gòu)一方面比較簡(jiǎn)單，另一方面對(duì)于要解決的問(wèn)題足夠聚焦。
Conduit service mesh也是由數(shù)據(jù)面板和控制面板組成。數(shù)據(jù)面板承載應(yīng)用實(shí)際的網(wǎng)絡(luò)流量。控制面板驅(qū)動(dòng)數(shù)據(jù)面板，并對(duì)外提供北向接口。
其中控制面板 (control plane) 主要由下面四個(gè)組件構(gòu)成:
- Controller : The controller deployment consists of multiple containers (public-api, proxy-api, destination, tap) that provide the bulk of the control plane’s functionality.
- Web : The web deployment provides the Linkerd dashboard.
- Prometheus : All of the metrics exposed by Linkerd are scraped via Prometheus and stored here. This is an instance of Prometheus that has been configured to work specifically with the data that Linkerd generates. There are instructions if you would like to integrate this with an existing Prometheus installation.
- Grafana : Linkerd comes with many dashboards out of the box. The Grafana component is used to render and display these dashboards. You can reach these dashboards via links in the Linkerd dashboard itself.
而數(shù)據(jù)面板 (Data Plane) 則是簡(jiǎn)單的包括你的 application 和透明的 sidecar proxy (默認(rèn)是用 Rust 語(yǔ)言編寫(xiě)的 linkerd-proxy)。
最后，Conduit 還提供了一個(gè)本地命令行工具 (CLI)，用于跟控制面板和數(shù)據(jù)面板交互。和一個(gè) Dashboard，用于服務(wù)監(jiān)控和治理。可以通過(guò)?linkerd dashboard?命令啟動(dòng)。
說(shuō)明：Conduit 后面合并到 Linkerd 2.0，因此本質(zhì)上 Linkerd 2.0 = Conduit。
對(duì)比
Linkerd 1.x 和 Envoy 比較相似，都是一種面向服務(wù)通信的網(wǎng)絡(luò)代理，均可實(shí)現(xiàn)諸如服務(wù)發(fā)現(xiàn)、請(qǐng)求路由、負(fù)載均衡等功能。它們的設(shè)計(jì)目標(biāo)就是為了解決服務(wù)之間的通信問(wèn)題，使得應(yīng)用對(duì)服務(wù)通信無(wú)感知，這也是Service Mesh的核心理念。
Linkerd 1.x和 Envoy 像是分布式的 Sidebar，多個(gè)類(lèi)似 Linkerd 1.x 和 Envoy 的 proxy 互相連接，就組成了 service mesh。
而 Istio 和 Conduit (Linkerd 2.x) 則是站在了一個(gè)更高的角度，它將Service Mesh分為了Data Plane和Control Plane。Data Plane負(fù)責(zé)微服務(wù)間的所有網(wǎng)絡(luò)通信，而Control Plane負(fù)責(zé)管理Data Plane Proxy:
而且Istio和Conduit引入了Kubernetes，這也彌合了應(yīng)用調(diào)度框架與Service Mesh之間的空隙。
5、Serverless
Serverless被翻譯為『無(wú)服務(wù)器架構(gòu)』，這個(gè)概念在2012年時(shí)便已經(jīng)存在，比微服務(wù)和Service Mesh的概念出現(xiàn)都要早，但是直到微服務(wù)概念大紅大紫之后，Serverless才重新又被人們所關(guān)注。
Serverless 的意思并不是無(wú)服務(wù)器，而是去除有關(guān)對(duì)服務(wù)器運(yùn)行狀態(tài)的關(guān)心和擔(dān)心，代碼在哪里運(yùn)行，需要多少容量，它們是否在工作，應(yīng)用是否跑起來(lái)正常運(yùn)行。
“Write your code, tell the system when to run it and you’re done.”
所有服務(wù)器的管理和擴(kuò)縮容對(duì)開(kāi)發(fā)者是透明的，開(kāi)發(fā)者只需要關(guān)心業(yè)務(wù)邏輯的開(kāi)發(fā)，其他的一切交給云服務(wù)提供者，比如Amazon Web Services (AWS Lambda), Google Cloud (Google Cloud Functions) 或者 Microsoft Azure (Azure Functions) 。
In this model, organizations only pay for the resources they use — actual consumption — rather than pre-purchased services based on guesswork. The server management and capacity planning decisions are completely hidden from the developer, thus the term “serverless.” The servers are fully abstracted away. Instead, a cloud provider, like Amazon Web Services (AWS Lambda), Google Cloud (Google Cloud Functions) or Microsoft Azure (Azure Functions) dynamically manages the assignment and distribution of resources.
但是其實(shí)這塊強(qiáng)調(diào)的是云平臺(tái)帶來(lái)的機(jī)器資源自由調(diào)度帶來(lái)的便利。跟 service mesh 2.0 其實(shí)沒(méi)有本質(zhì)上的區(qū)別，從這個(gè)意義上來(lái)說(shuō)，serverless 是目標(biāo)，service mesh 是解決方案。所以基本上，目前開(kāi)源的 serverless 框架，基本都是基于 k8s/mesos/docker compose這樣的容器編排和資源調(diào)度框架和 Service Mesh 框架實(shí)現(xiàn)。主要有如下這些：
最終的微服務(wù)解決方案 = Dev + Ops = Service Mesh + Kubernetes ？
這就是為什么有了 Linkerd 和 Envoy 之后，還會(huì)進(jìn)一步進(jìn)化出 Istio 和 Conduit。它們相對(duì)于老的 serive mesh 框架最大的特點(diǎn)就是基于 Kubernetes 設(shè)計(jì)，補(bǔ)足了Kubernetes在微服務(wù)間服務(wù)通訊上的短板。雖然Dubbo、Spring Cloud等都是成熟的微服務(wù)框架，但是它們或多或少都會(huì)和具體語(yǔ)言或應(yīng)用場(chǎng)景綁定，并只解決了微服務(wù)Dev層面的問(wèn)題。若想解決Ops問(wèn)題，它們還需和諸如Cloud Foundry、Mesos、或Kubernetes這類(lèi)資源調(diào)度框架做結(jié)合：
Kubernetes本身就是一個(gè)和開(kāi)發(fā)語(yǔ)言無(wú)關(guān)的、通用的容器管理平臺(tái)，它可以支持運(yùn)行云原生和傳統(tǒng)的容器化應(yīng)用。并且它覆蓋了微服務(wù)的Dev和Ops階段，結(jié)合Service Mesh，它可以為用戶(hù)提供完整端到端的微服務(wù)體驗(yàn)。
因此我們有理由推測(cè)，未來(lái)的微服務(wù)架構(gòu)和技術(shù)棧可能是如下形式:
云平臺(tái)(或者自建機(jī)房) 為微服務(wù)提供了資源能力（計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)等），容器 作為最小工作單元被 Kubernetes 調(diào)度和編排，Service Mesh 管理微服務(wù)的服務(wù)通信，最后通過(guò) API Gateway 向外暴露微服務(wù)的業(yè)務(wù)接口。
原文：http://arganzheng.life/microservice-architecture.html
轉(zhuǎn)載于:https://www.cnblogs.com/boxy/p/11474839.html
總結(jié)
- 上一篇： 中文实体、关系抽取工具
- 下一篇： JAVA：反射总结