面試都在問的微服務、服務治理、RPC、下一代微服務... 一文帶你完全搞懂！

時間 2020-04-06

標籤面試都在微服服務治理 rpc 下一代一文完全欄目快樂工作简体版

原文原文鏈接

文章每週持續更新，原創不易，「三連」讓更多人看到是對我最大的確定。能夠微信搜索公衆號「後端技術學堂」第一時間閱讀（通常比博客早更新一到兩篇）

單體式應用程序

與微服務相對的另外一個概念是傳統的單體式應用程序( Monolithic application )，單體式應用內部包含了全部須要的服務。並且各個服務功能模塊有很強的耦合性，也就是相互依賴彼此，很難拆分和擴容。php

說在作的各位都寫過單體程序，你們都沒意見吧？給你們舉個栗子，剛開始寫代碼你寫的helloworld程序就是單體程序，一個程序包含全部功能，雖然helloworld功能很簡單。html

單體應用程序的優勢

開發簡潔，功能都在單個程序內部，便於軟件設計和開發規劃。
容易部署，程序單一不存在分佈式集羣的複雜部署環境，下降了部署難度。
容易測試，沒有各類複雜的服務調用關係，都是內部調用方便測試。

單體應用程序的缺點

單體程序的缺點一開始不是特別明顯，項目剛開始需求少，業務邏輯簡單，寫代碼一時爽，一直爽。噩夢從業務迭代更新，系統日益龐大開始，前期的爽沒有了，取而代之的是軟件維護和迭代更新的無盡痛苦。java

因爲單體式應用程序就像一個大型容器同樣，裏面放置了許多服務，且他們都是密不可分的，這致使應用程序在擴展時必須以「應用程序」爲單位。git

當裏面有個業務模塊負載太高時，並不可以單獨擴展該服務，必須擴展整個應用程序（就是這麼霸道），這可能致使額外的資源浪費。程序員

此外，單體式應用程序因爲服務之間的緊密度、相依性太高，這將致使測試、升級有所困難，且開發曲線有可能會在後期大幅度地上升，令開發不易。相較之下「微服務架構」可以解決這個問題。github

微服務

微服務 (Microservices) 就是一些協同工做小而自治的服務。golang

2014年， Martin Fowler 與 James Lewis 共同提出了微服務的概念，定義了微服務是由以單一應用程序構成的小服務，本身擁有本身的行程與輕量化處理，服務依業務功能設計，以全自動的方式部署，與其餘服務使用 HTTP API 通訊。同時服務會使用最小的規模的集中管理 (例如 Docker) 能力，服務能夠用不一樣的編程語言與數據庫等組件實現。「維基百科」

舉例

仍是拿前面的 helloworld 程序來舉栗子，想象一下你是 helloworld 公司的 CTO（老闆還缺人嗎？會寫代碼的那種），假設大家公司的 helloworld 業務遍及全球，須要編寫不一樣語種的 helloworld 版本，分別輸出英語、日語、法語、俄語...如今世界有6000多種語言（奇怪的知識又增長了）。redis

有人會說這還不簡單我用switch case語句就完事了，同窗，不要較真我就是舉個例子，現實中的業務比 helloworld 複雜多了。好了，咱們姑且認爲按語言輸出是個龐大複雜的工做，這時候就能夠用微服務架構了，架構圖以下：數據庫

微服務與SOA

面向服務的體系結構 SOA (Service-Oriented Architecture) 聽起來和微服務很像，但 SOA 早期均使用了總線模式，這種總線模式是與某種技術棧強綁定的，好比：J2EE。這致使不少企業的遺留系統很難對接，切換時間太長，成本過高，新系統穩定性的收斂也須要一些時間，最終 SOA 看起來很美，但卻成爲了企業級奢侈品，中小公司都望而生畏。 apache

此外，實施SOA時會遇到不少問題，好比通訊協議（例如SOAP)的選擇、第三方中間件如何選擇、服務粒度如何肯定等，目前也存在一些關於如何劃分系統的指導性原則，但其中有不少都是錯誤的。SOA並無告訴你如何劃分單體應用成微服務，因此在實施SOA時會遇到不少問題。

這些問題再微服務框架中獲得很好的解決，你能夠認爲微服務架構是SOA的一種特定方法。

微服務架構

合久必分，鑑於「單體應用程序」有上述的缺點，單個應用程序被劃分紅各類小的、互相鏈接的微服務，一個微服務完成一個比較單一的功能，相互之間保持獨立和解耦合，這就是微服務架構。

微服務優勢

相對於單體服務，微服務有不少優勢，這裏列舉幾個主要的好處

技術異構性

不一樣服務內部的開發技術能夠不一致，你能夠用java來開發helloworld服務A，用golang來開發helloworld服務B，你們不再用爲哪一種語言是世界上最好的語言而爭論不休。

爲不一樣的服務選擇最適合該服務的技術，系統中不一樣部分也可使用不一樣的存儲技術，好比A服務能夠選擇redis存儲，B服務你能夠選擇用MySQL存儲，這都是容許的，你的服務你作主。

隔離性

一個服務不可用不會致使另外一個服務也癱瘓，由於各個服務是相互獨立和自治的系統。這在單體應用程序中是作不到的，單體應用程序中某個模塊癱瘓，必將致使整個系統不可用，固然，單體程序也能夠在不一樣機器上部署一樣的程序來實現備份，不過，一樣存在上面說的資源浪費問題。

可擴展性

龐大的單體服務若是出現性能瓶頸只能對軟件總體進行擴展，可能真正影響性能的只是其中一個很小的模塊，咱們也不得不付出升級整個應用的代價。這在微服務架構中獲得了改善，你能夠只對那些影響性能的服務作擴展升級，這樣對症下藥的效果是很好的。

簡化部署

若是你的服務是一個超大的單體服務，有幾百萬行代碼，即便修改了幾行代碼也要從新編譯整個應用，這顯然是很是繁瑣的，並且軟件變動帶來的不肯定性很是高，軟件部署的影響也很是大。在微服務架構中，各個服務的部署是獨立的，若是真出了問題也只是影響單個服務，能夠快速回滾版本解決。

易優化

微服務架構中單個服務的代碼量不會很大，這樣當你須要重構或者優化這部分服務的時候，就會容易不少，畢竟，代碼量越少意味着代碼改動帶來的影響越可控。

微服務缺點

咱們上面一直在強調微服務的好處，可是，微服務架構不是萬能的，並不能解決全部問題，其實這也是微服務把單體應用拆分紅不少小的分佈式服務致使的，所謂人多手雜，服務多起來管理的很差各類問題就來了。

爲了解決微服務的缺點，前輩們提出了下面這些概念。

服務註冊與發現

微服務之間相互調用完成總體業務功能，如何在衆多微服務中找到正確的目標服務地址，這就是所謂「服務發現」功能。

經常使用的作法是服務提供方啓動的時候把本身的地址上報給「服務註冊中心」，這就是「服務註冊」。服務調用方「訂閱」服務變動「通知」，動態的接收服務註冊中心推送的服務地址列表，之後想找哪一個服務直接發給他就能夠。

服務監控

單體程序的監控運維還好說，大型微服務架構的服務運維是一大挑戰。服務運維人員須要實時的掌握服務運行中的各類狀態，最好有個控制面板能看到服務的內存使用率、調用次數、健康情況等信息。

這就須要咱們有一套完備的服務監控體系，包括拓撲關係、監控（Metrics）、日誌監控（Logging）、調用追蹤（Trace）、告警通知、健康檢查等，防患於未然。

服務容錯

任何服務都不能保證100%不出問題，生產環境複雜多變，服務運行過程當中不可避免的發生各類故障（宕機、過載等等），工程師可以作的是在故障發生時儘量下降影響範圍、儘快恢復正常服務。

程序員爲此避免被祭天，須要引入「熔斷、隔離、限流和降級、超時機制」等「服務容錯」機制來保證服務持續可用性。

服務安全

有些服務的敏感數據存在安全問題，「服務安全」就是對敏感服務採用安全鑑權機制，對服務的訪問須要進行相應的身份驗證和受權，防止數據泄露的風險，安全是一個長久的話題，在微服務中也有不少工做要作。

服務治理

說到「治理」通常都是有問題才須要治理，咱們日常說環境治理、污染治理一個意思，微服務架構中的微服務愈來愈多，上面說的那些問題就更加顯現，爲了解決上面微服務架構缺陷「服務治理」就出現了。

微服務的那些問題都要公司技術團隊本身解決的話，若是不是大型公司有成熟的技術團隊，估計會很頭大。幸虧，有巨人的肩膀能夠借給咱們站上去，經過引入「微服務框架」來幫助咱們完成服務治理。

微服務框架

介紹一些業界比較成熟的微服務框架。

Dubbo

是阿里巴巴公司開源的一個Java高性能優秀的服務框架，使得應用可經過高性能的 RPC 實現服務的輸出和輸入功能，能夠和 Spring框架無縫集成。 Apache Dubbo |ˈdʌbəʊ| 是一款高性能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向接口的遠程方法調用，智能容錯和負載均衡，以及服務自動註冊和發現。2011 年底對外開源，僅支持 Java 語言。

官網： http://dubbo.apache.org/zh-cn/

Tars

騰訊內部使用的微服務架構 TAF（Total Application Framework）多年的實踐成果總結而成的開源項目。僅支持 C++ 語言，目前在騰訊內部應用也很是普遍。2017 年對外開源，僅支持 C++ 語言。

源碼： https://github.com/TarsCloud/Tars/

本命鵝廠 TARS 框架介紹 PPT 已下載，不想本身麻煩去找的同窗，在我公衆號「後端技術學堂」回覆「tars」獲取。

Motan

是新浪微博開源的一個Java 框架。Motan 在微博平臺中已經普遍應用，天天爲數百個服務完成近千億次的調用。於 2016 年對外開源，僅支持 Java 語言。

官方指南： https://github.com/weibocom/motan/wiki/zh_userguide

gRPC

是Google開發的高性能、通用的開源RPC框架，其由Google主要面向移動應用開發並基於HTTP/2協議標準而設計，基於ProtoBuf(Protocol Buffers)序列化協議開發。自己它不是分佈式的，因此要實現上面的框架的功能須要進一步的開發。2015 年對外開源的跨語言 RPC 框架，支持多種語言。

中文教程： https://doc.oschina.net/grpc?t=58008

thrift

最初是由 Facebook 開發的內部系統跨語言的高性能 RPC 框架，2007 年貢獻給了 Apache 基金，成爲 Apache 開源項目之一，跟 gRPC 同樣，Thrift 也有一套本身的接口定義語言 IDL，能夠經過代碼生成器，生成各類編程語言的 Client 端和 Server 端的 SDK 代碼，支持多種語言。

微服務框架和RPC

不少人對這兩個概念有點混淆，微服務框架上面咱們說過了，咱們再來看下RPC的概念。

什麼是RPC

RPC (Remote Procedure Call)遠程過程調用是一個計算機通訊協議。咱們通常的程序調用是本地程序內部的調用，RPC容許你像調用本地函數同樣去調用另外一個程序的函數，這中間會涉及網絡通訊和進程間通訊，但你無需知道實現細節，RPC框架爲你屏蔽了底層實現。RPC是一種服務器-客戶端（Client/Server）模式，經典實現是一個經過發送請求-接受迴應進行信息交互的系統。

二者關係

RPC和微服務框架的關係個人理解，微服務框架通常都包含了RPC的實現和一系列「服務治理」能力，是一套軟件開發框架。咱們能夠基於這個框架之上實現本身的微服務，方便的利用微服務框架提供的「服務治理」能力和RPC能力，因此微服務框架也被有些人稱做RPC框架。

下一代微服務架構

Service Mesh（服務網格）被認爲是下一代微服務架構，Service Mesh並無給咱們帶來新的功能，它是用於解決其餘工具已經解決過的服務網絡調用、限流、熔斷和監控等問題，只不過此次是在Cloud Native 的 kubernetes 環境下的實現。

特色

Service Mesh 有以下幾個特色：

應用程序間通信的中間層
輕量級網絡代理
應用程序無感知
解耦應用程序的重試/超時、監控、追蹤和服務發現

目前兩款流行的 Service Mesh 開源軟件 [Istio](https://istio.io/) 和 [Linkerd](https://linkerd.io/) 均可以直接在 kubernetes 中集成，其中 Linkerd 已經成爲雲原生計算基金會 CNCF (Cloud Native Computing Foundation) 成員。

Why Service Mesh

爲何現有微服務架構已經解決的問題還要用Service Mesh呢？這個問題問的好。

回答問題以前，先看下istio.io上對service mesh的解釋，我以爲挺好的，摘抄出來：

As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.
makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, with few or no code changes in service code.

試着總結一下：隨着微服務的增多複雜程度也增長，管理變得更加困難，微服務架構雖然解決了「網絡調用、限流、熔斷和監控」等問題，但大多數框架和開源軟件對原有業務是侵入式的，也就是須要在業務服務程序中集成相關的「服務治理」組件。

Service Mesh之於微服務，就像TCP/IP之於互聯網，TCP/IP爲網絡通訊提供了面向鏈接的、可靠的、基於字節流的基礎通訊功能，你再也不須要關心底層的重傳、校驗、流量控制、擁塞控制。

用了Service Mesh你也沒必要去操心「服務治理」的細節，不須要對服務作特殊的改造，全部業務以外的功能都由Service Mesh幫你去作了。它就像一個輕量級網絡代理 對應用程序來講是透明，全部應用程序間的流量都會經過它，因此對應用程序流量的控制均可以在 serivce mesh 中實現。

寫在最後

在IT世界沒有什麼技術是永不過期的，微服務架構的演進就是一個例子，從單體程序到微服務架構，再到service mesh架構，我不知道下一個技術迭代點是何時，但我知道微服務架構確定還會更新，IT人更應該創建終身學習習慣。
固然更重要的是擁有對技術的熱情，熱於擁抱變化、接受新技術，當我看到新技術我是興奮的，心裏os是厲害了，還能這麼玩！，但願你也有這般熱情，而不只僅是面向工資編程，生活會有趣不少。
老規矩。感謝各位的閱讀，文章的目的是分享對知識的理解，技術類文章我都會反覆求證以求最大程度保證準確性，若文中出現明顯紕漏也歡迎指出，咱們一塊兒在探討中學習。

原創不易，看到這裏動動手指，各位的「三連」是對我持續創做的最大支持，咱們下篇文章再見。