微服務：服務化框架落地的挑戰和核心需求

一、微服務架構概覽

1-1、微服務出現的意義所在

微服務出現的意義在哪裡呢？它的優勢有哪些呢？如何保障業務演進但是系統架構還是依然往好的方向發展呢？

一般而言，隨著公司產品線的不斷擴大，業務系統會越來越多，功能邏輯也越來越複雜，另外當前雲服務的發展勢頭很好，服務必然就會傾向於服務化的部署方式，這樣可以用來解耦服務之間的依賴，利於多團隊的協作，利於業務系統的最佳化和管理，也利於後續的服務排程和資源的精細化管理。

對我們後端服務而言，目前常見的開發語言: Golang、Java、C/C++、Lua 、PHP，並且各個部門所使用的語言種類不一。如果公司沒有一套規範化的流程和服務化框架，那麼公司內部的各個業務團隊、部門之間的技術體系就會越走越遠，從而會給公司的服務端系統的穩定性和可運維性帶來很大的挑戰，所以就需要一個統一的微服務架構的實踐統一解決當前的架構問題，防止架構腐化，從而提升我們後端系統的穩定性。這也是大多數網際網路公司微服務化的意義所在。

1-2、微服務定義

ThoughtWorks 的首席科學家，馬丁-福勒先生對微服務的一段描述，可以當做微服務的一個比較合適的定義：

微服務架構（Microservice Architect）是一種架構模式，它提倡將單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。每個服務執行在其獨立的程式中，服務與服務間採用輕量級的通訊機制互相溝通（通常是基於HTTP協議的RESTful API）。每個服務都圍繞著具體業務進行構建，並且能夠被獨立的部署到生產環境、類生產環境等。另外，應當儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。-- James Lewis and Martin Fowler

對於這段話，我個人的理解是，微服務是一種架構設計的風格，它的核心思想是進行服務模組化，是構建分散式系統的一種非常合適的方式。微服務需要具備如下特性：

• 微服務架構中的每個服務，要保持功能的職責單一，並且是可以獨立部署執行的。
• 微服務架構中的每個服務，可以選擇自己不同的合適自己團隊的語言，並且可以獨立管理，然後服務之間透過 RPC 或者 HTTP 協議進行互動
• 整個業務系統透過各個服務之間的組合呼叫來形成一套完整的業務流程

1-3、微服務的優勢

• 功能職責單一

• 每一個微服務的功能職責都很單一，很小、很獨立的一個小功能點就是一個服務
• 因為功能點小，那麼這個服務的程式碼量就會少，並且會很簡潔。

• 可獨立部署和執行

• 微服務的必要條件就是每個服務都可以獨立部署和執行，這樣就方便升級迭代。
• 開發、測試、部署都是獨立的

• 容錯性強

• 服務與服務之間，透過 RPC 進行互動，某一個服務異常，只會導致部分功能不可用，不會讓整個系統不可用。

• 隔離和松耦合

• 由於服務與服務之間，是透過 RPC 進行互動，這樣也就是他們具有強的隔離性，隔離性強會使得穩定性更高
• 他們之間沒有強耦合關係，每個服務可以自由選擇技術棧

• 可擴充套件性強

• 每個服務都可以獨立的伸縮，不同服務可以採用不同的擴充套件方法，從而可以提高業務的整體效能。

微服務架構本身並沒有特別的先進之處，關鍵在於當微服務、容器化、DevOps 這三者相結合之後，在業務規模很大時，透過拆分出多個獨立的服務進行開發、測試和運維，能夠快速迭代，加快業務研發的速度，這才是傳統架構向微服務架構轉變的最大價值。

1-4、微服務的拆分原則

橫向、縱向的拆分

• 從業務維度進行拆分。標準是按照業務的關聯程度來決定，關聯比較密切的業務適合拆分為一個微服務，而功能相對比較獨立的業務適合單獨拆分為一個微服務。
• 從公共且獨立功能維度拆分。標準是按照是否有公共的被多個其他服務呼叫，且依賴的資源獨立不與其他業務耦合。

基於分層設計的拆分

整個系統分為幾個層次，比如邏輯應用層、核心功能層、通用元件層，然後把這些通用元件層、核心功能層剝離出來，進行微服務化的拆分。

然後把每一層中，那些相對穩定的、可擴充套件的也要剝離出來，進行微服務化的拆分。

二、微服務實施的難點和挑戰

首先要說明的一點就是微服務落地有很多難點要解決，在微服務推進面臨的一些挑戰有：

1. 差異化的業務架構模型：公司現有的各個部門使用的框架不一樣、產品形態多，比如有如下這些

• Doubbo
• YAR
• HTTP

2. 多語言化的架構形態：公司涉及到所有常見的開發語言：Java、C++、 PHP、 Golang、 Lua、 Python等

3. 效能和可行性要求：如何提高效能、如何儘可能少的嵌入業務等

4. 微服務拆分後如何部署、如何治理

• 需要結合容器平臺
• 需要結合服務化框架系統
• 服務之間的通訊、鏈路追蹤、log日誌收集、問題排查定位

5. 如何運維管理：微服務大大增加了運維難度和複雜度

三、微服務框架落地的核心需求

微服務概念的提出者Martin Fowler其實在很早之前就說明了使用微服務需要具備的三個核心能力，分別是伺服器的快速擴容、監控和應用的快速部署。針對我自己的理解以及以往實際開發服務化框架中的一些經驗，我個人覺得，微服務化框架的落地，需要考慮並設計好如下一些需求點：

3-1、基礎設施

PaaS、LaaS 平臺

在雲原生時代，所有的雲服務廠商都有自己的 PaaS 產品，這樣也讓我們的微服務化體系建設的可執行落地帶來的極大的優勢和便利。

PaaS（平臺即服務）提供了一個用於開發、執行和管理應用程式的完整、靈活且經濟高效的雲平臺，PaaS 平臺具備分散式、服務化、服務治理、自動化運維、高可用、服務編排等一些優勢和特徵，並且可以很好的和 IaaS 平臺實現聯動。

DevOps 系列建設

微服務體系下，有大量的服務需要進行運維管理，包括測試、釋出上線、灰度放量、擴縮容等，那我們怎麼合理的去處理好這些運維能力呢，這裡就必須要有一套自動化運維管理體系，而這套東西，在業界，有一個叫做 DevOps 的文化，基於 DevOps 可以方便快捷的實現 CICD。CI 就是持續整合，是一種質量反饋機制，目的是儘快發現程式碼中的質量問題，CD 就是持續部署，是指能夠自動化、多批次、可控的實現軟體部署，控制故障的影響範圍或方便輕鬆的解決故障問題。透過 DevOps 的建設，可以實現軟體生產流水線和軟體運維自動化。

自動化測試平臺

微服務化會帶來服務模組增多的問題，會在一定程度上帶來開發成本的提升，所以需要透過配套的工具鏈來減少服務化後的開發成本。

自動化測試平臺的建設，可以有助於我們在開發測試階段就儘可能的減少系統出現的問題，提供一層保障。自動化測試平臺主要的目的是用來進行介面測試和介面撥測，後續也可以進一步去整合流量錄製和回放、全鏈路壓測等相關功能。

3-2、服務化框架

基礎的框架模組

1. 服務的基礎模組：通訊、序列化、服務註冊和發現、監控、管控平臺
2. 服務的使用：框架如何使用、如何接入、如何升級
3. 服務的部署形態：Client-Server 模式還是 API-Gateway 模式？

多語言的互通性

落地微服務化框架之前，公司內部肯定有多種不同的語言去實現各自的業務，比如常見的 Java、Golang、PHP、C/C++ 等，那麼我們如果想要推動進行改造，必然需要能夠支撐各自的語言，需要根據公司大眾語言各自實現一套對應語言的框架，然後不同語言之間，要能夠進行互通，也就是 A 語言實現的介面，B 語言是可以呼叫的。

互通方式的思路包括兩種：

• 第一種，簡單的透過 HTTP 協議，也就是各自語言都透過 HTTP 協議來呼叫
• 第二種，實現類似 gRPC 這種語言互通的服務化框架，透過 PB 進行 IDL 定義，然後內部的協議實現可以支撐不同的語言

多語言互通的必要性是非常大的，能夠實現多語言互通的話，推動落地的時候是一個大大的加分項，大家都會有意願去遷移改造，否則就很難推動，你總不能隨便就讓別人去換一種程式語言吧。

服務框架的效能

1. 服務的呼叫模型：Async、Sync、Concurrent
2. 框架的效能：所有服務都依賴框架，效能如果很差，那麼必然面臨著成本、可用性的壓力

3-3、服務的治理和管控

服務的治理和管控是服務高可用的必備手段，服務治理與管控包括幾大塊：服務的治理、服務的監控、服務的可用性保障

1. 服務的治理：服務提供方的管理、服務使用方的管理、服務依賴的管理、服務的呼叫管理、服務的註冊和發現、服務的部署和升級、服務的版本化管理
2. 服務的監控：資料採集、資料處理、鏈路跟蹤、白盒化的報表展示、系統級的監控
3. 服務的可用性：Failover、Failfast、負載均衡、過載保護、服務降級、頻率限制

3-4、標準化服務體系

服務化框架需要去解決標準化的問題，因為只有標準化後，才方便去解決問題，進行統一規範，不然面臨各種方案很容易導致解決問題的成本倍增。同時標準化後也更有利於後續統一化的工具鏈建設。這些標準化包括如下一些點：

1. 標準化服務的拆分方式。
2. 標準化服務的呼叫方式
3. 標準化服務的治理策略
4. 標準化服務的效能和監控指標

3-5、架構的相容和平滑演進

在服務化框架落地實施的時候，我們要考慮整體架構的平滑遷移和演進。因為原有不是微服務和統一服務化框架的體系下，大家都是各自為戰，那麼在進行統一的時候，我們必須要考慮到各個業務部門內部的遷移成本和服務的穩定性。如果我們退出一套框架，然後讓業務部門之間全部重構，那麼成本必然會很高，就會導致難以推進，可落地性就會面臨問題。因此我們要儘可能的使我們的框架可以在不同的協議之間相互呼叫，相容的目的是為了更好的落地而非更優雅的架構，這種相容性並逐步演進的思路尤其是在大業務體量之下，更為重要。比如在大公司，如果內部要統一一套框架，而這套框架的協議不能相容大部分已有服務架構，那麼一定是很難推動的。我在公司內部實際經歷各種框架、元件的處理姿勢都是這個套路

3-6、容器化和微服務結合

微服務化後，我們首先要面臨的一個問題就是成千上萬個服務如何進行管理、如何部署、部署在哪裡、服務之間如何解耦、如何進行環境隔離、如何保證同一個業務中的多個微服務例項能夠執行在相同的環境、每個服務所需要的資源如何分配、如何保證資源的利用率。

試想一下？直接部署在物理機上可行麼？部署在虛擬機器上可行麼？答案是都不行的！為啥？虛擬機器的粒度太大，即便是最小的物理機，至少也會有一個CPU核，但是微服務被拆分的非常小，這樣才能成為微服務，我們的微服務也許根本就用不到一個核，這樣對資源是一種極大的浪費。同時，虛擬機器的建立、銷燬相對比較耗時。如果直接部署在物理機上，那麼就更不行了，無法進行環境隔離、無有效利用資源。

這個時候，我們的容器化平臺就要出場了，Docker，這個大家都很熟悉的詞就是我們的突破口，Docker的建立和消耗可以在秒級別進行，同時Docker可以將執行環境進行隔離並且可以限制所使用的資源，計算粒度可以很小，可以是0.1個cpu，0.2個cpu這樣的粒度，也可以是100M、101M、1000M這樣任意值的記憶體。更為重要的是，業界出了很多容器編排管理的工具，如SwarmKit、Kubernetes、Mesos、Rancher等，可以對Docker進行全方位管理、監控，當然，現在最佳的肯定就是 Kubernetes 了。

所以，Kubernetes 容器化和微服務結合的優勢具體來說體現在以下幾個方面：

• 執行環境的隔離：容器為每個服務提供隔離、獨立的執行環境，在同一個伺服器上執行多種執行時相互有衝突的服務也不會出問題。
• 細粒度的資源分配：容器能夠很好的實現面向資源池的服務管理，每個服務可以更加精細化的分配 CPU 和記憶體等資源。
• 快速建立和銷燬：容器可以在秒級進行建立和銷燬，非常適合服務的快速構建和重組。
• 完善的管理工具：透過 kubernetes 可以很好的對服務進行編排和管理、排程