快速成為頂級架構師的內功修煉
查看直播——如何構建普適的企業級微服務架構
查看下篇文章
孫玄在2010年從浙江大學畢業後，就加入了百度，之後又加入過58集團、轉轉擔任最高級別架構師，最後選擇了自己創業，成立了新的IT在線教育平臺——奈學教育，致力於IT教育事業，在架構領域有著豐富的經歷和獨到的見解。
一、微服務架構下服務設計實踐
既然我們要構建一個普適的微服務架構，那麼如何去體現其“普適性”呢？有沒有一些比較通用的微服務架構來幫助我們完成這項任務呢？
首先我們要了解什麼是微服務架構，其最經典的定義如下圖所示。從定義上我們可以看出，微服務架構是一種將單體架構拆分成一系列小服務組合的方法。那麼，我們要如何去定義這個“小服務”呢？也就是說從一個單體變成很多小服務，我們要如何進行拆分呢？實際上，作為一個架構師，主要任務就是“拆”與“合”，如果做好了這兩點，就是一名優秀的架構師。
（一）如何“拆”？
有些公司的架構師會進行“甩鍋式”的拆分——定量拆分，比如說每一千行代碼進行一次拆分，但是會遇到一些問題，比如代碼行數不太“完美”，可能剛好在拆分後多了一行。雖然定量拆分是一種可行的拆分方式，但是可以說一定不是一種很好的拆分方式，或者說不是一種“優雅”的拆分方式。
無論何種事物，在底層的設計和“道”上都是相通的，唯一不同的在於“術”，只要我們把其中的一個方面吃透，再遷移到其他方面也是沒有問題的。
在講MS之前，我們先講講DB。假設你在負責一個電商的DB建設：你的數據有商品相關的、用戶相關的、交易相關的，一開始業務量比較小的時候，可以用一個單獨的數據庫，其中包括一個商品相關的表、一個用戶相關的表、一個交易相關的表。但是隨著業務量的增加，請求數也急劇增加，這時候你自然會想到將商品相關的數據、用戶相關的數據、交易相關的數據分別存入一個單獨的數據庫，就有了DB1、DB2和DB3，這種方法叫“分庫”。然而，隨著用戶數的進一步增加，DB2（用戶相關的DB）中的數據量過大，都放在一個表中會嚴重影響數據庫性能，這時你發現每一個用戶都有一個唯一的User ID，於是按照一定數目將用戶信息放在不同的表中，完成了拆分，這種方法叫“分表”。
上面的“分庫”方法是對數據庫的垂直拆分，“分表”是對數據庫的水平拆分。大家類比一下，既然數據庫可以進行垂直的拆分和水平的拆分，那麼微服務架構是否也可以進行“垂直”和“水平”的拆分呢？答案是肯定的，前面我們說過，他們在“道”上是相通的，區別在於“術”。
假設我們在負責一個電商業務架構，其中包括與用戶相關的功能、與商品相關的功能和與交易相關的功能。剛開始所有的請求都依靠一個單體來完成，隨著請求數的增加，我們要進行架構的拆分。正如上面講的，這時候我們至少要進行“垂直”和“水平”的拆分。
（1）垂直拆分
根據具體情況，這時候我們的垂直拆分要按照業務來進行拆分。我們知道，用戶和商品之間是邏輯關係，商品和交易之間也是邏輯關係，因此我們可以對其進行拆分，如下圖所示，對單體進行簡單的垂直拆分。
正如上圖我們將單體垂直拆分為用戶服務、商品服務和交易服務三部分，但是拆分的粒度比較粗，我們需要更細粒度的拆分。
比如用戶服務部分，主要包括用戶註冊、用戶登錄、用戶查詢等服務，其中用戶註冊是屬於“寫”的服務，用戶登錄和用戶查詢是屬於“讀”的服務，而一般情況下用戶註冊是比較重要的，也就是“寫”服務的重要性要大於“讀”服務；但是如果是一個互聯網業務，一般來講“讀”服務的數據量要遠遠大於“寫”服務的數據量，這時候如果用戶服務中同時包含了註冊和登錄服務，那麼當登錄服務的請求量足夠大的時候，一定會影響到註冊服務，因此我們可以按照功能對用戶服務模塊進一步的拆分，比如拆分成用戶註冊的微服務和用戶登錄/用戶查詢的微服務，實際上就是按照API的粒度進行拆分。
那麼是不是所有的服務都要按照API的粒度進行拆分呢？當然不是，我們要根據場景來進行拆分，比如業務量比較小的時候，即便用戶註冊和用戶登錄在同一個微服務下也不會影響，就不需要進行更細粒度的拆分。
如下圖所示，我們對用戶服務進行了更細粒度的拆分，但是也許商品的發佈量和交易量沒有達到一定數量級，就不需要進行更新粒度的拆分。
（2）水平拆分
我們仔細思考上面的例子，如果僅僅做一個垂直拆分，無非是將一個單體變成了多個單體，粒度仍然是比較粗的。這個時候，我們可以從整個請求的生命週期來看看，到底經歷了哪幾個過程，然後進行拆分，也就是做水平拆分。
我們把商品中的一件衣服拿出來作為例子，假設我們要發佈一個商品，它的整個生命週期是怎麼樣的呢？
如下圖所示，我們在APP上發佈商品，然後藉助通訊協議、傳輸協議與網關層進行消息傳遞，網關層完成鑑權、請求參數檢查等服務之後與業務邏輯層進行消息傳遞，業務邏輯層主要負責業務編排等服務，之後再發送請求給數據訪問層，數據訪問層完成CRUD、sharding、屏蔽底層數據差異性等功能，並從數據層獲取數據，數據來源可以是DB、Cache等等。
根據商品發佈服務的整個生命週期，我們在架構側完成了如下圖所示的水平拆分。那麼類似的，我們的用戶相關服務、交易相關服務也可以按照網關層、業務邏輯層、數據訪問層等進行相應的水平拆分。其中，網關層在商品相關服務和用戶相關服務、交易相關服務是相同的，我們可以將其部署成一個SaaS層，降低架構的工作量。
