|
個人覺得選擇微服務(wù)要慎重，要考慮清楚微服務(wù)可能帶來的挑戰(zhàn),。一定要結(jié)合自己的實際,，慎重地決定是否需要微服務(wù)化。網(wǎng)上關(guān)于微服務(wù)好處的介紹有很多,，這里我想特別強調(diào)的是,，從“人”的角度講，微服務(wù)帶來的優(yōu)勢和挑戰(zhàn),。微服務(wù)架構(gòu)下,，每個服務(wù)的復(fù)雜度大幅下降,，從而維護成本也大幅降低,。對于團隊來說，新人也可以更快地上手項目,，貢獻代碼,。交接項目也變得更加容易,。單一服務(wù)架構(gòu)下，隨著時間的推移,，項目的復(fù)雜度必然越來越高,，相關(guān)人員也會越來越多，從而代碼的合并頻率會逐漸下降,，權(quán)限越來越難以分配,，需要越來越重的測試，部署也越來越復(fù)雜,，頻率越來越低,。然而微服務(wù)也會帶來很多問題，例如如果設(shè)計不合理,，整體的復(fù)雜度會提高,。寫代碼的時候需要考慮調(diào)用失敗的情況，需要考慮分布式的事務(wù)（當(dāng)然很多時候是設(shè)計不合理導(dǎo)致的）,，從而對人提出了更高的要求,。總之，微服務(wù)帶來了很多優(yōu)勢,，同時也帶來了很多挑戰(zhàn),，我們需要認真的審視自己，這些優(yōu)勢對當(dāng)下的我們是否是優(yōu)勢,，這些挑戰(zhàn)對當(dāng)下的我們是否能hold住,。區(qū)分邊界服務(wù)和內(nèi)部服務(wù)。所謂邊界服務(wù)就是會接受公網(wǎng)流量的服務(wù),，比如處理 HTTP 請求的服務(wù),，反之就是內(nèi)部服務(wù)。邊界服務(wù)和內(nèi)部服務(wù)在安全方面的考慮是不一樣的（例如邊界服務(wù)需要做針對User的鑒權(quán)等等）,。 區(qū)分基礎(chǔ)和業(yè)務(wù)服務(wù),。業(yè)務(wù)服務(wù)追求變化，feature,，基礎(chǔ)服務(wù)追求穩(wěn)定,，性能。 微服務(wù)的調(diào)用,，一定要考慮調(diào)用會失敗,。微服務(wù)的提供方，一定要考慮調(diào)用可能會有bug（比如死循環(huán)）,。 沒有把握的做到合理拆分的時候可以選擇先不拆,，等到發(fā)現(xiàn)瓶頸了自然就知道怎么拆了。
關(guān)鍵問題二：微服務(wù)和 DevOps微服務(wù)除了是個技術(shù)活，更是個管理活,。一定得有和微服務(wù)相融的團隊組織方式和工作流程,。架構(gòu)組要負責(zé)微服務(wù)的基礎(chǔ)設(shè)施的建設(shè),，例如 CI/CD 系統(tǒng),，Kubernetes 集群， Service Mesh 集群,，監(jiān)控報警系統(tǒng),，日志收集系統(tǒng)，基礎(chǔ)工具和庫的構(gòu)建維護,。總之架構(gòu)組在團隊中的意義,，可以理解為是為內(nèi)部構(gòu)建 PaaS。業(yè)務(wù)團隊（無論是寫基礎(chǔ)業(yè)務(wù)的還是其他業(yè)務(wù)的）能從架構(gòu)組那里得到一個穩(wěn)定可靠的 PaaS 以及一攬子配套工具,。其次每個微服務(wù)要有固定的團隊負責(zé)（實踐中,，可以是對微服務(wù)分組，每組微服務(wù)對應(yīng)一組特定的人）,。每個團隊負責(zé)自己的微服務(wù)的從開發(fā)到上線,，到維護，到性能調(diào)優(yōu),，到Debug,。總之，每個團隊要對自己的微服務(wù)全權(quán)負責(zé),。在我們的實踐中,，每個微服務(wù)團隊由2-3人組成，有一個master,，負責(zé) DevOps 流程的建設(shè),，權(quán)限的分配等等一系列工作。例如我們的 DevOps 是基于 GitLab CI 和 Kubernetes 的,，所以master要負責(zé) gitlab-ci.yml ,，以及所有自己服務(wù)相關(guān)的 Kubernetes 的 deployment、job,、service 等等的編寫維護,。此外項目線上運行的狀況也要自己負責(zé)，例如設(shè)計自己特異的監(jiān)控指標(biāo),，報警策略等等,。這些反過來會指導(dǎo)自己的維護和調(diào)優(yōu)。不同的微服務(wù)團隊相互獨立,，通過gRPC 和 Celery 實現(xiàn)數(shù)據(jù)交換,。
從通信類型的角度看,，大概有三種類型：同步調(diào)用，異步調(diào)用,，廣播。在微服務(wù)的設(shè)計之初要想清楚調(diào)用關(guān)系以及調(diào)用方式,，哪些需要同步,，哪些可以異步，哪些需要廣播,，最好團隊內(nèi)部要有統(tǒng)一的認識,。然后就是要確定好調(diào)用協(xié)議了，例如常見的選擇有：同步調(diào)用：HTTP REST,、gRPC,、thrift，etc,。 異步調(diào)用：Sidekiq,、Celery，etc,。對應(yīng)的backend有 Redis,，各類 AMQP 實現(xiàn)，Kafka 等等,。 廣播：各類 AMQP 實現(xiàn),，Kafka，etc,。
對于如何選擇,，我們需要從很多角度去思考。網(wǎng)上有大量的 “X vs Y”的文章或問答,。其實無非就是從幾個角度：性能,，成熟度，易用性,，生態(tài),，技術(shù)團隊。我們的建議是：優(yōu)先選擇社區(qū)活躍,，以及和自己團隊技術(shù)棧相融的,。社區(qū)活躍的技術(shù)往往代表了趨勢和生態(tài)，而團隊技術(shù)棧的相容性則是能否落地成功的保證,。比如當(dāng)時扇貝選擇gRPC作為同步調(diào)用的接口協(xié)議,。主要考慮的就是兩點：1. 社區(qū)活躍，發(fā)展非常迅速,；2. 基于 HTTP/2,，與我們的技術(shù)棧相容。除了選擇協(xié)議，更加重要的應(yīng)該就是接口文檔的管理了,。最好接口文檔和代碼是強相關(guān)的,，就像 gRPC 的 proto 和生成出來的代碼那樣。否則人往往是有惰性的,，很有可能代碼改了文檔沒改,。總之，關(guān)于服務(wù)間通信,，我們需要做好：確定接口規(guī)范,，什么用同步調(diào)用，什么用異步,，什么用廣播,；同步調(diào)用用什么協(xié)議，異步用什么 確定接口協(xié)議,，以及思考接口文檔的管理,，接口文檔與代碼之間如何建立強聯(lián)系
服務(wù)治理是個非常大的話題，真的要鋪開來講,，分享的時間肯定講不完,。這里我們想先簡單地看一下服務(wù)治理要解決的問題，以及現(xiàn)在的一些解決方案,，發(fā)展趨勢,。最后以扇貝為例，簡單介紹下在一個真實的百萬日活的生產(chǎn)環(huán)境中,，服務(wù)治理是如何做的,。微服務(wù)化帶來了很多好處,，例如：通過將復(fù)雜系統(tǒng)切分為若干個微服務(wù)來分解和降低復(fù)雜度,，使得這些微服務(wù)易于被小型的開發(fā)團隊所理解和維護。然而也帶來了很多挑戰(zhàn),，例如：微服務(wù)的連接,、服務(wù)注冊、服務(wù)發(fā)現(xiàn),、負載均衡,、監(jiān)控、AB測試,，金絲雀發(fā)布,、限流、訪問控制,，等等,。這些挑戰(zhàn)即是服務(wù)治理的內(nèi)容,。除了新星 Service Mesh，現(xiàn)在還有諸如 Spring Cloud 等方案,。這些方案的問題是：1. 對代碼有侵入,，也就意味著，如果想換框架,，得改很多東西,。2. 語言特異性（Java），如果我們用的是 Go/Python,，或者我們的微服務(wù)不全是 Java,，就搞不定了,。之后便是 Service Mesh 方案了,，其實 DockOne 上關(guān)于 Service Mesh 的介紹太多了，我這里不想浪費大家時間,，就不贅述了,，我就直接介紹下我們是怎么用 Service Mesh 的。扇貝的 Service Mesh 是基于 Envoy 配合 Kubernetes 實現(xiàn)的,。首先介紹一些前提：扇貝的微服務(wù)全部容器化,，編排系統(tǒng)基于 Kubernetes，同步調(diào)用基于 gRPC,，異步基于 celery[rabbitmq],。開發(fā)語言以 Python 3、Node.js,、Go 為主,，Service Mesh 基于 Envoy。總體的方案是：Envoy 以 DaemonSet 的形式部署到 kubernetes 的每個 Node 上,，采用 Host 網(wǎng)絡(luò)模式,。 所有的微服務(wù)的 Pod 都將 gRPC 的請求發(fā)送到所在 Node 的 Envoy，由 Envoy 來做負載均衡,。如下圖所示：Envoy 中的 Route 類似于 Nginx 的 Location,，Cluster 類似于 Nginx 的 upstream，Endpoint 對應(yīng)于 Nginx 的 upstream 中的條目,。 之所以選擇 Envoy 而沒有用 Linkerd,，是因為當(dāng)時 Envoy 是對 HTTP/2 支持最好的。且資源消耗更少,。 之所以選擇 Host 網(wǎng)絡(luò)模式是為了最大化提高性能,。 對于 Enovy 而言，服務(wù)發(fā)現(xiàn)就是告訴 Envoy,，每個 Cluster 背后提供服務(wù)的實例的IP（對應(yīng)于 Kubernetes 也就是 Pod 的IP）是什么,。 最開始服務(wù)發(fā)現(xiàn)是利用 Kubernetes 的 DNS,，因此，在創(chuàng)建Service的時候,，要使用 ClusterIP: None,。 后來的服務(wù)發(fā)現(xiàn)是基于 Kubernetes 的 Endpoint API 實現(xiàn)了 Enovy 的 EDS（這個項目我們?nèi)蘸髸_源到 GitHub 上）。 對于 Envoy 而言,，實現(xiàn)熔斷,，只要實現(xiàn) rate limit service 就行了。我們基于Lyft/ratelimit 實現(xiàn)的 rate limit service,。 微服務(wù)之間的調(diào)用情況都可以通過 Envoy 的 statistic API反映出來,，所以我們針對 statistic API做服務(wù)調(diào)用的監(jiān)控報警。 同理,，調(diào)用日志也可以利用 Envoy 的 Access Log 來實現(xiàn),。 之所以不用istio，是因為生產(chǎn)環(huán)境真不能用,。性能問題,，穩(wěn)定問題太過突出。
我們的監(jiān)控報警方案是基于 Prometheus 做的,，分了三個級別：cluster級別,，包括Node的狀況，集群核心組件的狀況,，等等,。集群級別是架構(gòu)組關(guān)心的， 基礎(chǔ)服務(wù)級別是所有人都要關(guān)心的,，業(yè)務(wù)自定義級別就是微服務(wù)團隊關(guān)心的 基礎(chǔ)服務(wù)級別：包括 Service Mesh 的各種指標(biāo)（例如請求量,，請求時間等等），Redis,、MySQL,、RabbitMQ 等 業(yè)務(wù)自定義級別：包括各個微服務(wù)團隊自己設(shè)計的監(jiān)控指標(biāo)
報警直接報到同一個釘釘群，相互監(jiān)督,。上面這個例子就是我們的“單詞大師”團隊自定義的監(jiān)控指標(biāo),，包括他們特有的 “Match API Received”（也就是對戰(zhàn)匹配API調(diào)用次數(shù)）等等。至于日志的話,，基本還是沿用：Container -> stdout -> Filebeat -> Kafka -> Logstash -> ES（定期 archive）,。所有容器的日志都是直接打到stdout/stderr 的。多說一句,，我們的日志系統(tǒng)出了方便給程序員Debug,，同時還有承擔(dān)打點數(shù)據(jù)的收集的職責(zé)。所有的打點數(shù)據(jù),，也是通過日志系統(tǒng),，在 Kafka -> Logstash 那一步分揀出來的,。例如上圖就是我們分揀的部分 gRPC 的調(diào)用日志。
Q：Prometheus 只采集 Kubernetes 集群的指標(biāo)數(shù)據(jù),，那非 Kubernetes 的指標(biāo)數(shù)據(jù)用什么采集,？A：都是 Prometheus，應(yīng)用是可以裝 Prometheus 的client,，暴露自己的metrics的,，然后 Redis 什么的也都有exporter。Q：請問下日志如果都落到 stdout 的話,，會不會造成格式不一致,，從而導(dǎo)致收集和歸檔困難？比如說業(yè)務(wù)日志和中間件日志都打到 stdout,，在 Filebeat 或者 Logstash 內(nèi)是怎么處理的,？另外容器日志定期刪除的策略是什么？A：這是個好問題,，需要分揀的日志會在 message 的開頭做特定的標(biāo)記,。例如 [DATABEAT] 表示打點數(shù)據(jù),。ES 有很多工具可以做定期 archive 的,，策略比如保留多少天，多少月,，根據(jù)不同的數(shù)據(jù)的策略不同,。Q：Envoy 對性能的損耗有多大，自身的性能消耗有多大,？A：Envoy 是有性能損耗的,，因為 API 的平均響應(yīng)時間差不多在 100-150 ms，同時相比其帶來的好處,，我們認為這些損耗是值得的,，所以我們具體并沒有測算。Q：gRPC 做了服務(wù)注冊嗎,，gRPC 新增減少字段兼容性如何處理的,？A：服務(wù)注冊/發(fā)現(xiàn)是基于 Kubernetes 和我們寫的 Kubernetes Endpoint 到 Envoy eds 的轉(zhuǎn)化服務(wù)做的。Q：Istio 和 Envoy 什么關(guān)系,？A：Istio 包括一個控制面 + 數(shù)據(jù)面,，Envoy 可以作為 Istio 的數(shù)據(jù)面的一個實現(xiàn)。
Kubernetes入門與進階實戰(zhàn)培訓(xùn)
本次培訓(xùn)內(nèi)容包括：Docker基礎(chǔ),、容器技術(shù),、Docker鏡像、數(shù)據(jù)共享與持久化,、Docker三駕馬車,、Docker實踐,、Kubernetes基礎(chǔ)、Pod基礎(chǔ)與進階,、常用對象操作,、服務(wù)發(fā)現(xiàn)、Helm,、Kubernetes核心組件原理分析,、Kubernetes服務(wù)質(zhì)量保證、調(diào)度詳解與應(yīng)用場景,、網(wǎng)絡(luò),、基于Kubernetes的CI/CD、基于Kubernetes的配置管理等,，
|
