【云駐共創】如何使微服務更加便利

近些年微服務大行其道，許多開發者為了微服務而微服務，沒有考慮實際業務場景，只是為了追求技術熱點，盲目引入微服務，但又缺乏相應的技術掌控能力，最后影響了業務的穩定性。

微服務是在互聯網的發展中，大型公司開始面臨單體架構的局限的情況下誕生的。微服務讓部署服務器和管理基礎設施的工作變得非常容易。很快，一個圍繞微服務的產業發展壯大起來，它逐漸成為尋求擴展的企業默認架構。不幸的是，現在有許多公司由于這種選擇而掉進了各種之前想不到的坑里。

下圖是2015年到2021的百度搜索指數，微服務急速上升，然后開始趨于平緩。

微服務是在互聯網的發展中，大型公司開始面臨單體架構的局限的情況下誕生的，并非所有的項目都適用于微服務，就算是適用于微服務的項目，是否又可以很好的使用的微服務嗎？今天就來談一談華為云在使用微服務的時候，是如何處理微服務在實際開發中遇到的一些問題。

1：如何更快的交付新的云服務

1.1：僅僅是注冊發現嗎？

上圖是一個簡單的注冊發現過程，注冊發現的真的是在做一個注冊發現嗎？其實并不是的，我們需要一些其他的信息，可以幫助我們在管理微服務的時候能夠更加的高效。注冊發現應該承擔的更多職責，增加更多手段，可以技術管理者提供反饋。

首先我們在注冊微服務的時候，每一個微服務的實例會有很多的信息，會有版本號、微服務名、環境信息以及服務框架。這些我們都會注冊上來，最終發現是一個實例的IP和端口號。作為一個程序來說我們其實不太關心，更多人來關心的信息。所以說如果我們需要高效的管理服務的話，我們先要返回一個實體分離，分成一個基本不變的靜態信息與經常會變化的動態信息，從而能夠讓我們的微服務更快的拉起。

圖 1靜態信息

圖 2動態信息

1.2：服務的依賴應該如何管理

在開發微服務的功能中，我們很難管理架構，可能會出現服務重復調用和循環依賴，會增加項目的復雜度，導致項目很難去升級。

針對這個問題，我們可以采用審視依賴方向，按需推送實例變化，實時監控架構的依賴情況。

圖 3服務依賴管理

1.3：為什么應用API first

在微服務開發的過程中，架構師設計了一些api能力，卻不會去描述api能力。一般都是由開發去完成的，所以很難去管控開發所寫的api。

當我們的系統變成微服務的時候，微服務A依賴微服務B，在微服務B沒有完成前，微服務A很難開始。所以我們通過注冊到ServiceComb的API生成mock代碼進行集成測試。等到服務發布后，再切換到真實服務進行測試。應該可以在本地進行復雜分布式系統的測試，從而達到提升研發質量。

總結，通過靜態與動態信息分離，服務依賴管理，應用API first，可以給架構師提供一個審視視角，

例如，可以幫助架構師規劃合理的API設計，依賴關系；規范微服務元數據，防止濫用字段和冗余數據 ；提供可靠的注冊發現等。

2：遠遠不止交付業務功能

圖 4?冰山之下

在日常開發中這些非業務邏輯也占用了很大的工作量，我們采用了ServiceCenter的層疊架構，來減少工作量。

圖 5?ServiceCenter架構

ServiceCenter架構包含了一下

服務注冊發現：通過注冊發現完成 服務拓撲的感知

契約發現：每個服務具備一個契約 記錄，支持多種格式如Open API， gRPC proto

RBAC：基于角色的訪問控制，管 理員可以管理賬號，將賬號分發給 微服務或者不同人員

服務治理：針對微服務下發治理規 則，比如重試，限流，熔斷，路由 策略等

2.1如何進行不同交付局點，不同代碼分支交付

當我們面對產品定制化交付的時候，開發人員為了滿足不同客戶之間的差異需求,創建了很多分支，來交付不同的客戶。如果有更多的客戶，僅靠分支管理，是無法完成定制化交付的。我們可以通過以下幾點來完成這項工作。

2.1.1 將后端服務作為插件使用

常見的后端服務基本配額管理，認證鑒權服務，對象存儲服務。那是如何實現插件機制的呢？

定義后端接口

定義插件集，提供安裝API

2.2.2 沉淀需求基線

為什么要沉淀需求基線？所謂的基線就是必須要實現的東西。因為這些需求在每個不同的項目中都是必須要滿足的。

例如：

請求體必須做大小限制

API必須限流

密碼不能明文存儲

訪問進行認證鑒權

無單點故障

訪問審計

運維能力

當你發現公司內部不同 部門都在開發自己的協議做自己的服務治理時，再向將業務統一一個架構，一個工具鏈上，將非常困難。所以我們需要一個標準化運行時模型，因為不同部門可能有私有協議訴求，那么服務治理就交給核心框架完成。協議由業務部門決定自主研發或是集成現有協議。

圖 6標準化運行時模型

2.2.3 配置管理

在微服務項目中我們另外一個重點就是配置管理，我們實現了一個輕量級框架Go chassis，Go chassis可以遠端管理：生產環境；本地管理：集塵測試；內存管理：UT測試。

圖 7Go Chassis

2.2.4 易處理

微服務的幾大要素里，其中一個就是易處理。基本含義，快速啟動和優雅終止可最大化健壯性。 該要素原則體現到微服務應用有三點實踐： 微服務啟動時可以同時并發多個線程，采用懶加載方式，這樣實現快速啟動。 微服務終止是檢查所有資源都是否銷毀，所有監聽都要關閉，釋放所有的資源，最后什么也不留下地離開。 當非正常結束時，微服務自動恢復到默認狀態上。

協議服務管理:

1:統一Server模型

2:通過配置進行協議服務管理。

優雅停機過程：

停止心跳

注銷實例

中斷端口監聽

處理所有請求后退出

自定停機過程：

停機前后可以定制邏輯

可以徹底劫持go chassis原本停機過程

可以替換默認的系統信號

http的優雅停機實現：

2.2.5 輕量級內核

下圖是目前開源三方件依賴數量最少的工程，那我們的依賴都去了哪里？通過按需使用擴展能力和插件和定制的加載過程，來減少依賴。

圖 8go.mod

在go-chassis-extension工程，按需使用擴展能力和插件 。

在bootstrap中，可定制的加載過程

3：云原生生態構建

在生態上我們也做了一些自己的工作，例如在spring cloud上也做了一些擴展。

例如：

利用開源，只做擴展，不做封裝：保持原生spring cloud代碼寫法，并做特性增強

增強注冊發現：提供文檔管理，編寫一份spring cloud 代碼即可自動生成并上傳到服務中心

路由管理：自定義規則完成金絲雀發布，藍綠發布

增強配置管理：原生注解，接入到自研配置管理，提供配置一鍵回滾，歷史管理，推送軌跡等高級特性

3.1該不該用SideCar模式？

將應用程序的組件部署到單獨的進程或容器中，以提供隔離和封裝。此模式還可以使應用程序由異構組件和技術組成。這種模式被稱為Sidecar，因為它類似于連接到摩托車的邊車。在該模式中，邊車附加到父應用程序并為應用程序提供支持功能。 sidecar還與父應用程序共享相同的生命周期，與父項一起創建和退役。邊車圖案有時被稱為搭接圖案并且是分解圖案。

1：負載均衡、通用指標監控，路由管理等能力“卸載”到服務網格，適合自己業務的才是最好的 。

2： 卸載后，應用仍需要一個云原生開發框架，來提升團隊效能，除了異構系統對接，還有業務指標，優雅停機，配置治 理等云原生需要滿足的能力，微服務框架可能會逐漸演進為輕量級框架或者說叫“云應用框架” 。

3：?過分的市場熱度和吹捧，對最終用戶是一種傷害，技術是拿來用的，不是講出來的。

4：案例

4.1案例一（華為網管產品）

快速管理華為和三方設備

設備配置能力開放

4.2案例二（實時音視頻 RTC）

華為榮耀手機和智慧屏等終端的視頻通話后臺

已獨立上線公有云，支撐終端公司暢聯通話上億注冊用戶，基于go-chassis進行服務治理。

產品頁面：https://www.huaweicloud.com/product/rtc.html

4.3案例三（邊緣計算KubeEdge）

基于go chassis開發服務治理底座

管理著全國29個省、自治區的將近10萬邊緣節點，超過50萬邊緣應用的部署。支撐了1萬多個收費站中門架信息采集業務的不斷調整、更新，滿足了每日3億條以上的信息采集。

為日后車路協同、自動駕駛等創新業務的發展提供了良好的平臺支撐

Git地址：https://github.com/kubeedge/kubeedge

4.4案例四（某框架二次封裝）

本文整理自華為云社區內容共創活動第二期之【線下分享】華為云的微服務實踐。

查看活動詳情：

https://bbs.huaweicloud.com/forum/thread-111494-1-1.html

API 微服務

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。