一、微服務架構概覽

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、微服務拆分原則

橫向、縱向的拆分

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

基于分層設計的拆分

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

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

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

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

差異化的業務架構模型：公司現有的各個部門使用的框架不一樣、產品形態多，比如有如下這些DoubboYARHTTP多語言化的架構形態：公司涉及到所有常見的開發語言：Java、C++、 PHP、 Golang、 Lua、 Python等性能和可行性要求：如何提高性能、如何盡可能少的嵌入業務等微服務拆分后如何部署、如何治理需要結合容器平臺需要結合服務化框架系統服務之間的通信、鏈路追蹤、log日志收集、問題排查定位如何運維管理：微服務大大增加了運維難度和復雜度

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

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

3-1、基礎設施

PaaS、LaaS 平臺

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

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

DevOps 系列建設

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

自動化測試平臺

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

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

3-2、服務化框架

基礎的框架模塊

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

多語言的互通性

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

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

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

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

服務框架的性能

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

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

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

服務的治理： 服務提供方的管理、服務使用方的管理、服務依賴的管理、服務的調用管理、服務的注冊和發現、服務的部署和升級、服務的版本化管理服務的監控：數據采集、數據處理、鏈路跟蹤、白盒化的報表展示、系統級的監控服務的可用性： Failover、Failfast、負載均衡、過載保護、服務降級、頻率限制

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 可以很好的對服務進行編排和管理、調度

微服務框架 + K8s 容器平臺 是當今互聯網業務的黃金標準

最后

這篇文章首發在我微信公眾號【后端系統和架構】中，??點擊這里可以前往公眾號查看原文鏈接，如果對你有幫助，歡迎前往關注，更加方便快捷的接收最新優質文章?? 。 歡迎掃描關注：

推薦閱讀

推薦閱讀我的其他文章：

??《高并發架構和系統設計經驗》????《TCP 長連接層的設計和 在 IM 項目中實戰應用》????《萬字解讀云原生時代，如何從 0 到 1 構建 K8s 容器平臺的 LB（Nginx）負載均衡體系??》??《我終于統一了團隊的技術方案設計模板》??