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

前言

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

01 研發(fā)模式的起點：單體模式

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

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

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

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

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

單體模式的優(yōu)勢：

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

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

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

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

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

02 技術架構演化

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

1. MVC

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

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

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

2. 模塊化與分布式

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

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

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

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

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

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

03 業(yè)務導向：微服務

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

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

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

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

在阿里云官網(wǎng)，關于微服務的介紹：

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

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

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

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

04 微服務架構

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

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

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

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

05 微服務實踐

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

SpringCloud的架構圖? 翻譯by iCheer

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

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

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

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

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

06 總結

通過對微服務的學習，不難發(fā)現(xiàn)：

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

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

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

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

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

參考文章

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

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

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

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

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

《解析微服務架構（一）單塊架構系統(tǒng)以及其面臨的挑戰(zhàn)》作者：王磊

參考書籍

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

SpringCloud、Dubbo官方文檔：

https://spring.io/cloud

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

本文由 @iCheer 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議