對產品經理來說，了解技術相關基礎知識有助于理解需求的實現過程與原理，幫助與研發更好地溝通。而本文主要跟大家分享一下什么是“微服務”，以及它的起源、演化、架構與實踐。

前言

這段時間，程序猿哥哥突然主動找到產品汪，希望小汪提供一版最新的產品功能藍圖。小汪好奇向他們打聽，結果發現是技術組大佬提出了一個新概念“微服務”，涉及整個系統底層的重構，程序猿們內部也比較迷茫該。于是小汪就找了個機會，向技術組大佬請教了一下，到底什么是“微服務”。

01 研發模式的起點：單體模式

小汪問大佬，什么是“微服務”呀？

大佬回答說，你知道研發都有什么技術架構么？小汪搖了搖頭。技術大佬就說：

一個系統劃分為前端和后端，這個你懂吧？前端就是用戶看得到、摸得著的，例如APP、小程序、網頁等等、管理后臺等等；后端是用戶看不見的，負責進行邏輯處理和儲存各類數據的。

小汪說，這個我知道，我還知道前后端分離呢！

大佬接著說：在系統發展的早期，后端就只有一套系統，所有功能的代碼都寫在這套系統中，我們稱之為“單體模式”。

單體模式的優勢：

• 容易開發：不講究復用、遇到什么新需求都造個新“輪子”，這樣最容易開發了；
• 容易回溯：遇到問題的時候很容易定位是哪個新造的“輪子”出了問題；
• 容易部署：也就是大家常說的“發版”，系統新功能上線，因為只有一套后端代碼，所以把改過的代碼直接發布一次就行了；
• 容易克隆：別人想買這個系統時，直接Ctrl+C，Ctrl+V一下就好了。

隨著需求越來越多，功能越來越復雜，單體模式的弊端就會暴露出來：

• 迭代和維護成本增加：系統規模還小時，一個新功能可能只與三五個已有功能關聯，所以改動起來很容易。但是隨著系統功能越來越多，一個新功能可能跟十幾個、甚至幾十個已有功能關聯時，要改其中一個功能，可謂牽一發而動全身，這下工作量就會變得陡然增加。
• 工作交接十分困難：不同功能由不同的程序員寫的，又調用了別的程序員寫的代碼，交接起來哪些是自己寫的可能都分不出來，別人也不知道該怎么維護。
• 重構難度十分巨大：萬一哪一天性能或者復雜度到了極限，需要對代碼進行優化或重構，舊的代碼重度耦合，根本下不去手。

物理學上，兩個和兩個以上的體系或者兩者運動形式之間相互作用而彼此影響以至于聯合起來的現象叫做“耦合”。

這里的“耦合”是指系統模塊間相互依賴、互相影響的意思。模塊間的耦合度是指模塊之間的依賴關系，包括控制關系、調用關系、數據傳遞關系。模塊間聯系越多，其耦合性越強，同時表明其獨立性越差。

02 技術架構演化

由于單體模式長遠來看明顯弊大于利，所以程序員就開始思考如何有規劃的寫代碼。

1. MVC

MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設計典范，用一種業務邏輯、數據、界面顯示分離的方法組織代碼。

MVC是從代碼意義的層面出發，將代碼分為了負責調度用的Controller控制器、負責業務邏輯和數據庫處理的Model模型、負責最終數據呈現的View視圖三部分。

相對于最開始的“一鍋粥”的混沌狀態，現在代碼間有了一些邊界，程序員分工、代碼定位也更清晰了。

2. 模塊化與分布式

MVC解決了代碼內部管理的不少問題，但是從整個系統的視角來看，依然是一個單體。隨著業務規模越來越大，某幾個功能的流量可能占用了服務器絕大部分資源，于是就產生了兩個問題：

• 功能的穩定性如何保障？
• 單臺服務器的處理能力達到瓶頸后如何處理？

聰明的程序員就想到，把關鍵的業務邏輯和主系統剝離開來，形成獨立的模塊，這樣關鍵邏輯就能單獨運作，不受系統其它邏輯故障的影響。當該模塊用戶量多的時候，還可以把模塊多復制幾份同時運行，這樣其中一個模塊不幸掛了，那么其他模塊還能接替他繼續運作。

把多個模塊放在同一臺服務上，并沒有解決服務器處理能力極限的問題，于是就找老板要為這臺服務器升級配置，結果一出價格，嚇得老板直哆嗦。

配置提高一點，價格就高了很多，花同樣的錢能買好幾臺原來配置一樣的機器。如果改成買多幾臺機器，然后想辦法讓這些機器處理能力能疊在一起，性能還可以遠超升級的配置。

于是就有了分布式的誕生，多買幾臺幾臺服務器，讓他們同時工作。服務器還可以選擇部署在全國不同的地方，實現了用戶的就近區域訪問，讓不同地區用戶都能享受最佳的訪問速度。

03 業務導向：微服務

分布式的架構看似幫程序員們解決了很多的問題，但是新的問題又隨之而來：

• 按什么標準去將代碼獨立成新模塊？按技術的喜好、代碼的作用、還是按業務模塊區分？
• 未來獨立的模塊越來越多，那該如何管理？

微服務的到來，就為這些問題打開了新思路。最經典的微服務的概念，是Martin Fowler于2014年的一篇文章《Microservices – the new architectural style》中闡述的：

微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相協作（通常是基于HTTP協議的RESTful API）。每個服務都圍繞著具體業務進行構建，并且能夠被獨立的部署到生產環境、類生產環境等。

在阿里云官網，關于微服務的介紹：

微服務能夠將業務單元按照獨立部署和發布的標準進行抽取和隔離，一個大而全的復雜應用程序能夠拆分成幾個微小的相互獨立的微服務，當其中的某一服務無法支撐時，可以橫向水平擴展保證應用的高可用性，具有獨立應用生命周期管理、獨立版本開發與發布等能力。

從這些定義中，我們可以總結出幾個關鍵詞：

• 小：將大系統拆成一組小的服務
• 獨立：每個服務互相獨立
• 輕：我們可以簡單理解為代碼之間通過一套標準化、大眾化的方式互相溝通
• 業務：服務圍繞著業務進行構建。這里要介紹一個概念“康威定律”，這就是為什么微服務最終選擇了以業務結構作為其服務劃分的依據原因。

馬爾文·康威1967提出的：“設計系統的架構受制于產生這些設計的組織的溝通結構?！蓖ㄋ椎膩碇v：產品必然是其（人員）組織溝通結構的縮影。

04 微服務架構

微服務其實是對模塊化和分布式的一種升級。

首先，后端增加了統一的“門面”——網關。有了網關之后，前端就不需要知道眾多的服務他們分布在哪里，只需要請求網關，由網關將需求傳遞到相應的服務中。網關還能自動幫前端找到最快且穩定的服務節點，讓前端體驗更勝一籌。

諸多的服務分散在不同的地方，為了將這些服務組織管理起來，知道他們用途、狀態信息，避免后續發展成一共有多少個服務都無法統計，就誕生了服務池的“管理機構”。所有服務都必須在管理機構內注冊登記、及時上報自身情況。

稍微復雜點的功能，都需要多個服務互相配合才能完成的。單體模式時代，由于只有一套系統，程序員順藤摸瓜就能找到bug出在哪?，F在存在多個獨立的服務，程序員必須每個服務逐一排查故障，這就讓找bug根源問題變得非常困難，于是就需要一套故障追蹤機制，記錄前端請求在后端實現的全鏈路，以便發現問題出在哪。

05 微服務實踐

為了讓程序員可以更好將系統架構向微服務遷移，于是就衍生出了微服務的代碼框架，其中比較出名的方案有SpringCloud、Dubbo兩家，我們來簡單看看他們他們的官方示例圖。

SpringCloud的架構圖? 翻譯by iCheer

從SpringCloud的架構中不難看出微服務的相對于原有的分布式架構的新特征：

• 網關：對前后端的溝通進行統一的管理。
• 注冊中心：用于對所有服務進行管理，服務必須在注冊中心注冊登記才能使用
• 配置中心：每個服務的配置不是在各自服務內進行，而是統一放在“配置中心”便于管理
• 分布式追蹤器：就是用來配合程序員定位一個功能鏈條中是哪個環節出了問題

Dubbo的架構路線圖? 翻譯by iCheer

里面有一些比較專業名詞，未來有機會再另外講解

從Dubbo的架構路線圖里，我們能更直觀的看到上文講的技術架構演化歷程：從單一架構到MVC，再到分布式，然后把分布的服務進行統一管理。

06 總結

通過對微服務的學習，不難發現：

微服務其實不是一種具體的技術，不是某家公司出品的軟件（如Docker）或語言（如Java、Python）。微服務也沒有形成一個標準的定義（如C/S、B/S）或設計模式（如MVC），事實上，研發行業內許多大牛都對微服務有著自己的見解。

其實在早在十多年前（就是這么早）一些公司就開始嘗試將大系統不斷的進行拆解探索，最著名的案例其一就是Netflix網飛，自2009年開始對系統進行拆分、上云，微服務的概念就在這些公司的不斷探索中逐漸成型、完善。

微服務更像是技術架構的一種新思潮，一種正在不斷迭代的、用業務的思想解決技術問題的思路，你也可以認為這是程序員們對“人人都是產品經理”的一種側面實踐。

業務驅動下產生的微服務，無疑讓寫代碼這件事變得更具挑戰性，但卻讓程序更能直接表達其價值，能讓企業的業務更好、更快的發展。

下期預告：如果說“微服務”其實是一種技術思潮，那產品經理為何要了解微服務，微服務對產品設計有何幫助？

參考文章

《微服務架構定義那點事》作者：時間的朋友

《什么是微服務架構》作者：老劉

《微服務入門這一篇就夠了》作者：centychen

《微服務寫的最全的一篇文章》作者：AI喬治

《微服務（Microservice）那點事》作者：小云棲

《解析微服務架構（一）單塊架構系統以及其面臨的挑戰》作者：王磊

參考書籍

《微服務架構與實踐》作者：王磊

SpringCloud、Dubbo官方文檔：

https://spring.io/cloud

http://dubbo.apache.org/zh-cn/docs/user/preface/background.html

本文由 @iCheer 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議