web前端開發學習哪家學，CSS定位

Service Mesh技術作為新一代微服務架構，有效的解決了目前微服務架構和治理過程中的痛點問題，一經推出便引起很大的反響，近兩年持續成為架構領域的熱點。特别是Google聯合Lyft等公司推出的Istio，架構優雅，功能強大，迅速成為Service Mesh領域的明星項目。

什麼是Service Mesh

作為Service Mesh技術探索和實踐的先行者，全球第一個真正的Service Mesh項目Linkerd負責人、Buoyant公司創始人兼CEO William Morgan第一次完整地闡述了Service Mesh。按照William Morgan的定義，Service Mesh是一個緻力于解決服務間通信的基礎設施層，其負責在現代雲原生應用的複雜服務拓撲下實作請求的可靠傳遞，在實踐中Service Mesh通常實作為一組輕量級網絡代理，這些代理與應用程式部署在一起，并且對應用程式透明。

從上述Service Mesh的定義看，基礎設施層是Service Mesh的定位，緻力于解決本書第1章提出的微服務基礎設施标準化、配置化、服務化和産品化問題；服務間通信是Service Mesh技術面對的問題域，對微服務屏蔽通信的複雜度，解決微服務的通信治理問題；請求的可靠傳遞是Service Mesh的目标；輕量級網絡代理是Service Mesh的部署方式；對應用程式透明是Service Mesh的亮點和特色，Service Mesh接入對業務無侵入，可以非常友善地擷取Service Mesh帶來的便捷性，算是Service Mesh的一大優勢。

綜合來看，Service Mesh主要解決使用者如下3個次元的痛點需求。

完善的微服務基礎設施

Service Mesh通過将微服務通信下沉到基礎設施層，屏蔽了微服務處理各種通信問題的複雜度，可以看成是微服務之間的抽象協定層，抽象層面可以看成是TCP/IP協定棧的一部分。對于微服務的開發者來說，比如目前使用HTTP或者Thrift進行RPC通信時，你不需要關注TCP/IP這一層的具體實作；有了Service Mesh之後，微服務也不再需要關注RPC通信（包含服務發現、負載均衡、流量排程、限流降級、監控統計等）的一切細節，真正像本地調用一樣使用微服務，通信相關的一切工作直接交給Service Mesh。

是以，對于一些需要通過微服務改造提升業務靈活性，但沒有相應技術能力的中小團隊來說，可以借助Service Mesh提供的完善微服務基礎設施，加速微服務的落地。

語言無關的通信和鍊路治理

功能上，Service Mesh并沒有提供任何新的特性和能力，Service Mesh提供的所有通信和服務治理能力在Service Mesh之前的技術中均能找到，比如Spring Cloud就實作完善的微服務RPC通信和服務治理支援。Service Mesh改變的是通信和服務治理能力提供的方式，通過将這些能力實作從各語言業務實作中解耦，下沉到基礎設施層面，以一種更加通用和标準化的方式提供，屏蔽不同語言、不同平台的差異性，這樣不僅有利于通信和服務治理能力的疊代和創新，業務使用的時候也會更加友善。

Service Mesh避免了多語言服務治理上的重複建設，通過Service Mesh語言無關的通信和服務治理能力，助力多語言技術棧的效率提升。

通信和服務治理的标準化

1. 微服務治理層面，Service Mesh是标準化、體系化、無侵入的分布式服務治理平台。
2. 标準化方面，Sidecar成為所有微服務流量通信的限制标準，同時Service Mesh的資料平面和控制平面也通過标準協定進行互動。
3. 體系化方面，從全局考慮，提供多元度立體的微服務可觀測能力（Metric、Trace、Logging），并且提供體系化的服務治理能力，比如限流、熔斷、安全、灰階等；最為重要的是，Service Mesh通過透明無侵入的方式提供全面的服務治理能力，對微服務本身不會帶來直接影響。

通過标準化，帶來一緻的服務治理體驗，減少多業務之間由于服務治理标準不一緻帶來的溝通和轉換成本，提升全局服務治理的效率。

Service Mesh的基本模式

根據Service Mesh的發展曆程和使用方式，我們可以把Service Mesh劃分為兩個模式。

Sidecar模式

在Service Mesh發展早期，Service Mesh以Sidecar的形态存在。Sidecar模式下，網絡代理服務在微服務旁邊，為微服務提供通信和鍊路治理功能。是以，資料平面代理服務也經常被簡稱為Sidecar。

此時，隻有資料平面的網絡代理服務沒有控制平面，和外部基礎設施服務的互動直接在網絡代理服務中進行。

Sidecar模式可以看作是第一代Service Mesh，代表有早期的Linkerd和Envoy。

第一代Service Mesh通過采用Sidecar模式，通過将通信和通信鍊路治理功能從微服務中剝離出來，實作了通信基礎設施的下沉和服務化，這裡也展現了架構解耦的思想，通過解耦減少了微服務的負擔。

第二代Service Mesh模式

Sidecar模式的Service Mesh有一個突出的問題，将通信和通信鍊路治理的所有功能都放到這個代理服務中，導緻資料平面代理很重，并且由于承載了太多的特性和功能，使得資料平面代理的更新和修改特别頻繁，頻繁的更新和更新會導緻代理服務出問題的機率增大，影響代理服務的穩定性。同時，Service Mesh模式下，資料平面代理承載了微服務通信的全部流量，對穩定性要求極高，這個服務的任何故障都會對整個系統的穩定性産生很大的影響。為了解決上述頻繁更新和穩定性之間的沖突，将政策和配置決策邏輯從代理服務中脫離出來，形成了獨立的控制平面，這就是第二代Service Mesh。

第二代Service Mesh最重要的标志就是控制平面和資料平面分離。資料平面和控制平面并不是新的概念，路由器/交換機等資料通信産品架構上，就有運作于專門處理器上的控制平面和多個獨立運作、用于路由或交換功能的資料平面。SDN（Software Defined Network，軟體定義網絡）将資料平面和控制平面分離，控制平面具有可程式設計性，使得網絡更加智能、靈活和易擴充，激發了網絡技術的又一次革命。

第二代Service Mesh借鑒了SDN的思路，基于控制平面和資料平面分離思想，有了完善的控制平面：①所有的代理服務都由控制平面掌控，因為控制平面可以控制整個系統，是以提供了強大的控制能力和政策能力；②将具體的控制邏輯從資料平面移除，簡化了資料平面的設計，資料平面不需要和外部系統進行互動，資料平面完全聚焦在變更頻率很低的流量路由和轉發邏輯上，提升了資料平面的穩定性。

Service Mesh架構

第二代Service Mesh的基本架構上分為資料平面和控制平面兩個部分，大緻如下圖所示。

資料平面

資料平面負責代理微服務之間的通信，具體包含RPC通信、服務發現、負載均衡、降級熔斷、限流容錯等，資料平面可以認為是将Spring Cloud、Dubbo等語言相關的微服務架構中通信和服務治理能力獨立出來的一個語言無關的程序，并且更注重通用性和擴充性。在Service Mesh中，不再将資料平面代理視為一個個孤立的元件，而是将這些代理連接配接在一起形成一個全局的分布式網絡。

控制平面

控制平面負責對資料平面進行管理，定義服務發現、路由、流量控制、遙測統計等政策，這些政策可以是全局的，也可以通過配置某個資料平面節點單獨指定。控制平面通過一定的機制将政策下發到各個資料平面節點，資料平面節點在通信時會使用這些政策。

4. 感悟

最近的面試，有以下幾點感悟：

1. 電話面試比視訊面試靠譜

   視訊面試有點尬的感覺，而且有時會卡頓，相比之下電話面試就不會存在這些問題

   個人更喜歡電話面試的形式

2. 面試前多一些準備

   複工後的第2天，面了第一家公司，完全沒狀态，答的一塌糊塗

   建議面試前一定要調整好狀态，特别是這次春節在家宅的時間有點長，更要調整

3. 一定要有的放矢

   一定要對你所投遞崗位的公司有一定了解，避免面試通過了你又不想去，浪費雙方時間

   建議對自己投遞的崗位和公司多花點時間去仔細了解下

   一定要對你所投遞崗位的公司有一定了解，避免面試通過了你又不想去，浪費雙方時間

   建議對自己投遞的崗位和公司多花點時間去仔細了解下