本文爲《架構探險-輕量級微服務架構》（黃勇著）序面試
微服務來了，有了「服務」這兩個字，這注定又是個一說就明白、一舉例就糊塗、一討論就吵架的概念。微服務的出現有其必然的商業背景和架構哲學，如何更好的認識微服務的內涵、如臂使指的應用微服務架構，仍是有着不少挑戰的，這也許就是本書被命名爲「架構探險」的緣由。架構
企業數字化轉型驅動架構升級運維
互聯網經濟深入改變了咱們身邊的商業環境，消費者的生活方式日益數字化，人們能夠在任什麼時候間、任何地點利用線上、線下渠道體驗無縫購物，運用社交媒體表達自我，企業也在運用多種技術手段，發揮數字化潛力，改善客戶聯繫，促進企業業務模式的轉型。Gartner認爲，數字化就是把人、事、物和商業聯繫起來，創建新的商業模式。將來的企業都將是IT企業，IT將從後臺走向前臺，從ERP、CRM等內部流程優化爲主的業務，逐步轉向內外兼修的模式，從而實現商業創新。這一變化要求IT架構更加靈活的與上下游企業協做，更加快速的響應客戶的個性化需求，更加彈性的應對無時不在的客戶請求並提供良好的客戶體驗，同時雲計算、大數據等技術的出現也爲上述改變提供了新的技術選擇，咱們正面臨B/S多層架構出現後新的一次架構升級，而微服務架構就在這個架構升級過程當中應運而生。微服務
分而治之的哲學是微服務的理論基礎測試
把大的問題分解爲容易解決的小問題，找到小問題的解決辦法，再來解決大問題，就是分而治之的哲學。正如萬事萬物由分子、原子組成同樣，軟件也能夠分解爲基本單元，以這樣的基本單元進行開發、測試、維護，是解決大規模系統建設的思路。分而治之首先要解決如何分的問題，企業軟件的分法應該是以業務驅動的，而不是技術驅動的，也就是分解爲獨立的業務邏輯，而這樣的不可再分的業務邏輯就是微服務。大數據
凡事有一利必有一弊，細分爲微服務後，勢必帶來部署、測試、信息集成難度的提升，分而治之除了「分」以外，還須要「治」。傳統恐龍型ERP是一個面向組織的軟件，完備、複雜、響應變化慢，適合業務穩定的狀況，而數字化時代客戶個性化的要求讓咱們從這種面向組織的軟件，逐漸演變爲面向個體的軟件。例如從前的EHR軟件是爲人力資源部門服務的，總體開發、總體實施，而如今咱們會從個體的角度規劃軟件，能夠先從招聘專員開始作一個面試管理的流程，逐步推出新的流程，完善現有的流程。這些面向個體的流程就是微應用，企業應用將由無數個微應用組成。微服務則是一個技術概念，能更好解決微應用的技術實現問題，是一個事物的不一樣側面，所謂「橫當作嶺側成峯，遠近高低各不一樣」，微服務和微應用是事物的一體兩面。正由於微服務實際就是一個業務邏輯，所以作好微服務須要從微應用的維度考慮，將分解開的邏輯造成一個總體，要從多渠道接入、客戶體驗、數據管理、應用交付、運維全方位的視角考慮，這就是分而治之中實現「治」的體驗，也是微服務架構須要解決的問題。優化
站在SOA的肩膀上踐行微服務雲計算
微服務是一個新概念，但這毫不是一個全新架構，更不是一個包治百病的架構。因爲有服務二字，很容易讓人聯想到面向服務架構（SOA），其實微服務架構屬於應用技術架構，和以B/S 爲表明的三層架構相對應，強調將巨石型應用拆分爲由微服務組成的應用，在數據上也視狀況從集中的存儲拆解爲更小的存儲單元。而SOA屬於企業架構的範疇，從企業架構出發把業務分解爲不一樣領域的服務，不一樣物理系統提供不一樣服務，注重系統之間經過服務互聯互通的規範，對服務如何實現並不關注。所以，面向服務架構的服務應該是一個業務意義的服務，而微服務是系統中的技術服務，更關注服務的實現，雖然提供了業務意義的服務，可是不能混爲一談。微服務使用也不是無限度的，事實上因爲數據一致性等問題的限制，不能無限度拆分微服務，能夠把微服務分爲系統對外提供的遠程服務、系統內部的遠程服務和系統內部的本地服務，顯式聲明、明確職責。事實上，在企業架構上使用SOA支撐業務，而在應用技術架構上使用微服務架構，是一個合適的選擇。spa
黃柳青博士是我和黃勇共同的導師，他在2004年所著《軟件的涅槃》一書中指出：「互聯網時代的企業應用定義，正發生革命性的變化… 橫向的部門互動、實時的企業間互動、多樣的交互渠道、靈活的業務規則，使得原有意義上的獨立應用不復存在… 對軟件設計者來講，能直觀地分割，並具備最小內部耦合的軟件結構是簡約之美… 美的軟件是軟件企業與軟件開發者的終極目標」，那時候他把這種全新的軟件生產模式稱爲「面向構件」。回頭看來，微服務正是「面向構件」在數字化時代的解讀，用微服務架構實現軟件之美，加速企業數字化轉型。設計