政策 1——停止挖掘
Law of Holes 是說當自己進洞就應該停止挖掘。對于單體式應用不可管理時這是最佳建議。換句話說，應該停止讓單體式應用繼續變大，也就是說當開發新功能時不應該為舊單體應用添加新代碼，最佳方法應該是将新功能開發成獨立微服務。如下圖所示：
除了新服務和傳統應用，還有兩個子產品，其一是請求路由器，負責處理入口（http）請求，有點像之前提到的 API 網關。路由器将新功能請求發送給新開發的服務，而将傳統請求還發給單體式應用。
另外一個是膠水代碼（glue code），将微服務和單體應用內建起來，微服務很少能獨立存在，經常會通路單體應用的資料。膠水代碼，可能在單體應用或者為服務或者二者兼而有之，負責資料整合。微服務通過膠水代碼從單體應用中讀寫資料。
微服務有三種方式通路單體應用資料：
- 換氣單體應用提供的遠端 API
- 直接通路單體應用資料庫
- 自己維護一份從單體應用中同步的資料
膠水代碼也被稱為容災層（anti-corruption layer），這是因為膠水代碼保護微服務全新域模型免受傳統單體應用域模型污染。膠水代碼在這兩種模型間提供翻譯功能。術語 anti-corruption layer 第一次出現在 Eric Evans 撰寫的必讀書 Domain Driven Design，随後就被提煉為一篇白皮書。開發容災層可能有點不是很重要，但卻是避免單體式泥潭的必要部分。
将新功能以輕量級微服務方式實作由很多優點，例如可以阻止單體應用變的更加無法管理。微服務本身可以開發、部署和獨立擴充。采用微服務架構會給開發者帶來不同的切身感受。
然而，這方法并不解決任何單體式本身問題，為了解決單體式本身問題必須深入單體應用做出改變。我們來看看這麼做的政策。
政策 2——将前端和後端分離
減小單體式應用複雜度的政策是講表現層和業務邏輯、資料通路層分開。典型的企業應用至少有三個不同元素構成：
- 表現層——處理 HTTP 請求，要麼響應一個 RESTAPI 請求，要麼是提供一個基于 HTML 的圖形接口。對于一個複雜使用者接口應用，表現層經常是代碼重要的部分。
- 業務邏輯層——完成業務邏輯的應用核心。
- 資料通路層——通路基礎元素，例如資料庫和消息代理。
在表現層與業務資料通路層之間有清晰的隔離。業務層有由若幹方面組成的粗粒度（coarse-grained）的 API，内部包含了業務邏輯元素。API 是可以将單體業務分割成兩個更小應用的天然邊界，其中一個應用是表現層，另外一個是業務和資料通路邏輯。分割後，表現邏輯應用遠端調用業務邏輯應用，下圖表示遷移前後架構不同：
單體應用這麼分割有兩個好處，其一使得應用兩部分開發、部署和擴充各自獨立，特别地，允許表現層開發者在使用者界面上快速選擇，進行 A/B 測試；其二，使得一些遠端 API 可以被微服務調用。
然而，這種政策隻是部分的解決方案。很可能應用的兩部分之一或者全部都是不可管理的，是以需要使用第三種政策來消除剩餘的單體架構。
政策 3——抽出服務
第三種遷移政策就是從單體應用中抽取出某些子產品成為獨立微服務。每當抽取一個子產品變成微服務，單體應用就變簡單一些；一旦轉換足夠多的子產品，單體應用本身已經不成為問題了，要麼消失了，要麼簡單到成為一個服務。
排序那個子產品應該被轉成微服務
一個巨大的複雜單體應用由成十上百個子產品構成，每個都是被抽取對象。決定第一個被抽取子產品一般都是挑戰，一般最好是從最容易抽取的子產品開始，這會讓開發者積累足夠經驗，這些經驗可以為後續子產品化工作帶來巨大好處。
轉換子產品成為微服務一般很耗費時間，一般可以根據獲益程度來排序，一般從經常變化子產品開始會獲益最大。一旦轉換一個子產品為微服務，就可以将其開發部署成獨立子產品，進而加速開發程序。
将資源消耗大戶先抽取出來也是排序标準之一。例如，将記憶體資料庫抽取出來成為一個微服務會非常有用，可以将其部署在大記憶體主機上。同樣的，将對計算資源很敏感的算法應用抽取出來也是非常有益的，這種服務可以被部署在有很多 CPU 的主機上。通過将資源消耗子產品轉換成微服務，可以使得應用易于擴充。
查找現有粗粒度邊界來決定哪個子產品應該被抽取，也是很有益的，這使得移植工作更容易和簡單。例如，隻與其他應用異步同步消息的子產品就是一個明顯邊界，可以很簡單容易地将其轉換為微服務。
如何抽取子產品
抽取子產品第一步就是定義好子產品和單體應用之間粗粒度接口，由于單體應用需要微服務的資料，反之亦然，是以更像是一個雙向 API。因為必須在負責依賴關系和細粒度接口模式之間做好平衡，是以開發這種 API 很有挑戰性，尤其對使用域模型模式的業務邏輯層來說更具有挑戰，是以經常需要改變代碼來解決依賴性問題，如圖所示：
一旦完成粗粒度接口，也就将此子產品轉換成獨立微服務。為了實作，必須寫代碼使得單體應用和微服務之間通過使用程序間通信（IPC）機制的 API 來交換資訊。如圖所示遷移前後對比：
此例中，正在使用 Y 子產品的 Z 子產品是備選抽取子產品，其元素正在被 X 子產品使用，遷移第一步就是定義一套粗粒度 APIs，第一個接口應該是被 X 子產品使用的内部接口，用于激活 Z 子產品；第二個接口是被 Z 子產品使用的外部接口，用于激活 Y 子產品。
遷移第二步就是将子產品轉換成獨立服務。内部和外部接口都使用基于 IPC 機制的代碼，一般都會将 Z 子產品整合成一個微服務基礎架構，來出來割接過程中的問題，例如服務發現。
抽取完子產品，也就可以開發、部署和擴充另外一個服務，此服務獨立于單體應用和其它服務。可以從頭寫代碼實作服務；這種情況下，将服務和單體應用整合的 API 代碼成為容災層，在兩種域模型之間進行翻譯工作。每抽取一個服務，就朝着微服務方向前進一步。随着時間推移，單體應用将會越來越簡單，使用者就可以增加更多獨立的微服務。 将現有應用遷移成微服務架構的現代化應用，不應該通過從頭重寫代碼方式實作，相反，應該通過逐漸遷移的方式。有三種政策可以考慮：将新功能以微服務方式實作；将表現層與業務資料通路層分離；将現存子產品抽取變成微服務。随着時間推移，微服務數量會增加，開發團隊的彈性和效率将會大大增加。
最後
看完美團、位元組、騰訊這三家的面試問題，是不是感覺問的特别多，可能咱們又得開啟面試造火箭、工作擰螺絲的模式去準備下一次的面試了。
開篇有提及我可是足足背下了1000道題目，多少還是有點用的呢，我看了下，上面這些問題大部分都能從我背的題裡找到的，是以今天給大家分享一下網際網路工程師必備的面試1000題。
注意：不論是我說的網際網路面試1000題，還是後面提及的算法與資料結構、設計模式以及更多的Java學習筆記等，皆可分享給各位朋友，直接戳這裡即可免費下載下傳
網際網路工程師必備的面試1000題
而且從上面三家來看，算法與資料結構是必備不可少的呀，是以我建議大家可以去刷刷這本左程雲大佬著作的《程式員代碼面試指南 IT名企算法與資料結構題目最優解》，裡面近200道真實出現過的經典代碼面試題。
，是以我建議大家可以去刷刷這本左程雲大佬著作的《程式員代碼面試指南 IT名企算法與資料結構題目最優解》，裡面近200道真實出現過的經典代碼面試題。