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

前言

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

01 研發(fā)模式的起點(diǎn)：?jiǎn)误w模式

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

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

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

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

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

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

• 容易開發(fā)：不講究復(fù)用、遇到什么新需求都造個(gè)新“輪子”，這樣最容易開發(fā)了；
• 容易回溯：遇到問題的時(shí)候很容易定位是哪個(gè)新造的“輪子”出了問題；
• 容易部署：也就是大家常說的“發(fā)版”，系統(tǒng)新功能上線，因?yàn)橹挥幸惶缀蠖舜a，所以把改過的代碼直接發(fā)布一次就行了；
• 容易克隆：別人想買這個(gè)系統(tǒng)時(shí)，直接Ctrl+C，Ctrl+V一下就好了。

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

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

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

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

02 技術(shù)架構(gòu)演化

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

1. MVC

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

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

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

2. 模塊化與分布式

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

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

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

把多個(gè)模塊放在同一臺(tái)服務(wù)上，并沒有解決服務(wù)器處理能力極限的問題，于是就找老板要為這臺(tái)服務(wù)器升級(jí)配置，結(jié)果一出價(jià)格，嚇得老板直哆嗦。

配置提高一點(diǎn)，價(jià)格就高了很多，花同樣的錢能買好幾臺(tái)原來配置一樣的機(jī)器。如果改成買多幾臺(tái)機(jī)器，然后想辦法讓這些機(jī)器處理能力能疊在一起，性能還可以遠(yuǎn)超升級(jí)的配置。

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

03 業(yè)務(wù)導(dǎo)向：微服務(wù)

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

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

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

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

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

微服務(wù)能夠?qū)I(yè)務(wù)單元按照獨(dú)立部署和發(fā)布的標(biāo)準(zhǔn)進(jìn)行抽取和隔離，一個(gè)大而全的復(fù)雜應(yīng)用程序能夠拆分成幾個(gè)微小的相互獨(dú)立的微服務(wù)，當(dāng)其中的某一服務(wù)無法支撐時(shí)，可以橫向水平擴(kuò)展保證應(yīng)用的高可用性，具有獨(dú)立應(yīng)用生命周期管理、獨(dú)立版本開發(fā)與發(fā)布等能力。

從這些定義中，我們可以總結(jié)出幾個(gè)關(guān)鍵詞：

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

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

04 微服務(wù)架構(gòu)

微服務(wù)其實(shí)是對(duì)模塊化和分布式的一種升級(jí)。

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

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

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

05 微服務(wù)實(shí)踐

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

SpringCloud的架構(gòu)圖? 翻譯by iCheer

從SpringCloud的架構(gòu)中不難看出微服務(wù)的相對(duì)于原有的分布式架構(gòu)的新特征：

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

Dubbo的架構(gòu)路線圖? 翻譯by iCheer

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

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

06 總結(jié)

通過對(duì)微服務(wù)的學(xué)習(xí)，不難發(fā)現(xiàn)：

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

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

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

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

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

參考文章

《微服務(wù)架構(gòu)定義那點(diǎn)事》作者：時(shí)間的朋友

《什么是微服務(wù)架構(gòu)》作者：老劉

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

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

《微服務(wù)（Microservice）那點(diǎn)事》作者：小云棲

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

參考書籍

《微服務(wù)架構(gòu)與實(shí)踐》作者：王磊

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)許可，禁止轉(zhuǎn)載

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