本書從開發與運維兩方面分別對微服務架構的實踐過程進行描述，全書分為上下兩冊，上冊偏重于開發，下冊偏重于運維。在上冊中讀者會學習到微服務架構所需的開發技能，使用 Spring Boot 搭建微服務開發框架，使用 Node.js 搭建微服務網關，使用 ZooKeeper 實現微服務注冊與發現，使用 Docker 封裝微服務，使用 Jenkins 部署微服務。通過閱讀上冊，讀者可輕松搭建一款輕量級微服務架構。

序一
微服務，應用開發的新起點


研究現在的軟件體系，不難發現：現在的軟件專家們仍需要與大量的需求、設計、代碼的細節打交道。出于項目實施時間、投入資源等方面的限制，軟件往往以實現若干具體的用戶功能需求為目標。專家們沒有時間，也沒有精力去追求軟件的美學目標。日復一日，隨著用戶功能需求的變化，軟件項目成為大量代碼的隨機而無序的堆積，奇丑無比。許多功能成一旦完成項目，就恐避之不及，不愿再去碰自己幾個月來夜以繼日的勞動成果。
黃勇的《架構探險：輕量級微服務架構》一書，融合了軟件設計的最新理念，系統性介紹了微服務的設計、開發、運維等各方面，書中不僅僅是技術的描述和講解。看到黃勇在技術方面這么多年的不斷積累和提煉，我很欣慰。
微服務的興起和移動應用的快速發展相對應。移動應用的基本框架是事件和響應，用戶在碎片化的時間和地點，按自己的節奏完成綜合起來是一個復雜的事情。這不同于傳統軟件，往往是流程和復雜業務驅動的過程和算法。移動計算所需要的跨界溝通和協作，在傳統應用架構中則很難實現，而這恰恰是微服務的優勢所在。微服務從技術的視角，使用各種協議和框架，便于不同開發者軟件碎片之間的協同工作。但是各種軟件交互協議并不稀缺，總是不斷地出現各種協議的標準。微服務的成功使用，需要注意微服務在軟件重用方面的能力，正是這種能力，使得微服務的使用更加具有普遍的意義。不同于傳統的構件或服務，微服務的調用參數接口具有更大的融合性和靈活性。微服務的調用，不需要拘泥于嚴格的數據類型，而是遵循更高層次的語法結構。特別是應用軟件走向人工智能的時代，微服務將更深的演化帶來更智能的微服務對接。微服務對于傳統的過程式軟件，是一個破壞性的改變。這一特征既給了微服務無限的想象空間，也給實施帶來了很多挑戰。并不是每個應用，特別是成熟領域的軟件應用都適合微服務的改造。但是對于移動應用領域和跨應用跨企業的對接，是一個很必要的選擇。
我早年寫了一些關于 SOA 和“面向構件”方面的東西，有人問我：“SOA和微服務有何差異？”我認為：SOA 的核心還是企業級應用。最大的差異，是微服務對于調用參數的宏定義，語義的適應性，使得微服務的復用性大大提升。比較有意思的是，新的微服務調用參數體系，和普元EOS非常類同，15年前我們就是這樣設計的。微服務是SOA后的一個突破性的東西，不是簡單的落地，SOA 本身也有落地，比如普元的EOS就是SOA落地后的產品。SOA到微服務一方面是網絡協議的提升，更加適應跨應用跨企業的服務調用。還有人問我：“構件和微服務到底有什么區別？”我認為：構件是裝配、開發的視角，一臺機器由一個個構件裝配而成；服務是運行、傳動的視角，能量從活塞到輪胎傳播。微服務用代碼來開發，但微服務可以當成一個構件裝配到應用。兩邊視角不同，但是微服務給了軟件模塊更多生命力。構件是靜態的，服務是動態的。
這本書對于微服務架構的介紹非常完整，如果你和你們的企業正在開發移動應用，或者對已有的應用正在規劃架構性的重構，這本書很值得一讀。

—黃柳青


序二
微服務，我們如何與你相處


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


微服務是近年來備受關注的話題，它的出現讓我們想起了十年前的 SOA（Service-Oriented Architecture，面向服務架構），但它比傳統的 SOA 更容易理解，也更容易實踐，它將“面向服務”的思想做得更加徹底。
當國外一些知名技術公司成功實踐了微服務以后，這股熱潮就吹遍了國內的大街小巷，大家街頭巷尾都在聊微服務，對它眾說紛紜且褒貶不一。有人說它非常好，但就是“玩不起”，為何會這樣呢？
我們不妨帶著這個問題來簡單介紹一下，究竟什么才是微服務。
微服務是一種分布式系統架構，它建議我們將業務切分為更加細粒度的服務，并使每個服務的責任單一且可獨立部署，服務內部高內聚，隱含內部細節，服務之間低耦合，彼此相互隔離。此外，我們根據面向服務的業務領域來建模，對外提供統一的 API 接口。微服務的思想不只是停留在開發階段，它貫穿于設計、開發、測試、部署、運維等軟件生命周期階段。
可見，我們提到的微服務，實際上是一種架構思想，我們不妨稱它為“微服務架構”。
微服務架構看起來如此之好，我們真的就需要它嗎？
微服務架構建議我們按照業務來切分服務，我們完全可以選擇最合適的技術來實現具體的服務，只需確保對外提供的 API 接口保持一致即可，也就是說，微服務架構使我們技術選型的自由度更加寬廣了。既然系統可拆分為多個服務，這樣非常有利于我們對每個服務進行監控，可不斷收集每個服務的性能指標數據，當某個服務出現性能瓶頸時，會發出預警，我們可隨時水平地擴展該服務，以支撐更大的流量，而不至于復制整個系統。由于服務之間彼此隔離，相互之間不會產生影響，因此我們可借助技術的手段來實現自動化部署，這會使我們的部署過程變得更加高效。
其實微服務架構的優點數不勝數，但是大家可能還是不敢用，因為它對我們的技術要求具有一定的挑戰。比如，我們需要一個自動化部署系統，也需要解決分布式系統帶來的一系列問題，還需要服務之間能做到彼此隔離且互不影響，同時還不能影響通信過程中所帶來的性能開銷。因此很多人認為，只有大公司或強悍的技術團隊才能玩得起微服務架構，自己只能“遠觀”卻不能“近玩”。甚至還有人認為，微服務架構實際上就是以前談論多年而難以落地的 SOA。
實際上，我們認為微服務架構的本質仍然符合 SOA 思想，只不過它比 SOA 更容易落地。為了證明這件事情，我們經過了大量的實踐，借助了許多優秀的開源技術，搭建了一款“輕量級微服務架構”。實踐證明，該架構不僅可以適應大中型公司的業務變化，還能滿足中小型公司的快速增長。我們真心地希望這款輕量級微服務架構能夠幫助更多的技術愛好者以及更多的技術團隊，順利地走出技術困境，以全新的視角去迎接新的挑戰。
不得不提醒大家的是：微服務并不是萬靈丹！它不能包治百病，我們更不要為了微服務而去微服務。而是需要根據自身的情況，靈活地選擇最合適的技術，通過技術的手段實現更高的目標。
為什么寫這本書？
我一直很關注服務化方面的技術，記得在 2014 年，我偶然發現國外技術博客中有人在寫關于“微服務”方面的概念與技術。坦白地講，當我第一次看到微服務時，并沒有對它產生濃厚的興趣，我當時認為微服務是笨重的，它和傳統的 SOA 沒有太大的區別，同樣都是服務化，只不過微服務更加細粒度而已。直到 Docker 容器技術逐步成熟起來，越來越多的人開始使用 Docker 來封裝應用程序，并借助 Docker 技術讓軟件交付變得更加靈活而高效，這讓我不由地對微服務的未來產生了強烈的期待，我堅信微服務將伴隨著 Docker 技術成為未來軟件開發與運維的核心武器。
我開始瘋狂地學習微服務，研究它的各種架構模式與應用領域，開始自己動手做一些練習，并在公司內部大力推廣這種新架構。在實踐中，我獲得了一點收獲，曾在一些技術大會與企業內訓中講過微服務的原理與實踐。我發現一個問題，雖然大家對微服務都非常關注，但往往卻不知應該如何開始，應該使用哪些技術來搭建微服務架構，以及在實踐中應該如何避免掉進坑里。甚至有些人還認為微服務只是大公司才玩得起的東西，因為它需要借助像 SOA 那樣重量級的基礎設施，需要付出大量的成本，但收益卻不一定。其實，我想告訴大家的是，微服務架構并非這樣，它應該是輕量級的，它應該是很容易上手的，它應該是任何公司想用就敢用的。雖然國內外已經有幾本關于微服務方面的好書了，但我仍然希望這本書能為大家在微服務實踐方面帶來微薄的價值。
我們可以把微服務架構想象成海面上的一座冰山，看得見的部分是開發，看不見的部分是運維，一個好的微服務架構需要同時關注開發和運維兩個方面。本系列書分上下兩冊，上冊偏開發，下冊偏運維。
您適合看這本書嗎？
如果您還沒聽說過微服務，或者您聽說了但不知道它究竟是什么，或者您正在嘗試微服務的實踐，那么這本書就非常適合您。不管您是一名開發人員還是一名運維人員，如果您向往成為一名優秀的微服務架構師，那么這本書更加值得您反復閱讀和實踐。
本書是如何組織的？
第1章：微服務架構設計概述。
從為什么需要微服務架構開始講起，接著描述微服務架構是什么，以及微服務架構有哪些特點，最后以如何搭建微服務架構來結束本章。本章是全書的概述，從一個宏觀的視角來講解微服務，為后續章節搭建了一個骨架。
第2章：微服務開發框架。
本章我們將使用流行的 Spring Boot 來搭建微服務開發框架，對 Spring Boot 是什么，以及如何使用 Spring Boot 都做了描述，此外還對 Spring Boot 的重要產品級特性做了相關介紹。通過學習本章，大家可掌握 Spring Boot 的基本使用方法，并具備開發微服務接口的技能。
第3章：微服務網關。
本章我們將學習 Node.js 技術，描述 Node.js 是什么，以及如何使用 Node.js，此外還對 Node.js 的重要高級特性做了補充。最后我們將使用 Node.js 搭建一個微服務網關基礎框架，后續章節會對此框架進行擴展。
第4章：微服務注冊與發現。
本章我們將學習 ZooKeeper 框架，從認識 ZooKeeper 開始，到如何使用 ZooKeeper。最后我們將使用 ZooKeeper 實現一個簡單的服務注冊組件，并結合第3章中介紹的微服務網關框架，使用 Node.js 實現一個服務發現組件。
第5章：微服務封裝。
本章我們將學習 Docker 技術，從了解 Docker 是什么開始，到如何使用 Docker，并通過手工和Dockerfile 的方式構建 Docker 鏡像，此外還會介紹 Docker Registry 的使用方法，最后將以 Spring Boot 與 Docker 做一個整合來結束本章。通過學習本章，大家可熟練使用 Docker，為后續自動化運維提供基礎。
第6章：微服務部署。
本章是上冊的最后一章，我們將使用 Gitlab 管理項目源碼，使用 Jenkins 搭建持續集成系統，最后基于 Jenkins + Gitlab + Docker 搭建一款微服務的自動化部署平臺。通過學習本章，大家可將開發與部署更加高效地銜接起來。
我要致謝的人
我要把這本書送給我的女兒，雖然她根本就看不懂，因為她只有三歲。記得在她剛出生那年，我開始寫技術博客；在她一歲那年，我開始做開源項目；在她兩歲那年，我開始寫自己的第一本書；在她三歲之時，這本書出版了。為了自己的事業，我借用了陪伴她成長的時間，這個時間是我這輩子都無法償還給她的，希望她長大后能看到我送給她的這本書，或許她會理解我現在所做的一切。
我最想感謝的人還是我的妻子，她為了料理家務和照顧女兒，選擇放棄自己的事業，全力支持我的事業，這種“放棄自己，成全他人”的精神，我是無法做到的。我有這樣的好妻子，讓我感到無比驕傲，同時我也需要給自己更高的目標，回報她對我的付出。
十年前我離開自己的家鄉，獨自來到上海打拼，這些年很少陪伴在自己父母的身邊，因為工作太忙而遺忘了對父母的問候，我很愧疚自己所做的一切。感謝我的父母對我的無私付出，以及對我事業的認可與鼓勵，希望他們看到這本書后能為我感到高興。
感謝與我一起創業的伙伴們，大家能在一起共事是一種緣分，他們在工作上給我提供了許多幫助，和他們一起工作是我最開心的事情，我也能感受到自己在成長。他們還為本書提供了專業的建議，以及為本書提供了大量寶貴的實踐經驗。
感謝電子工業出版社博文視點的陳曉猛編輯，在寫作過程中曉猛多次鼓勵我，他曾說“寫書就是登山”，每當我寫不動了，想放棄了，他就會鼓勵我“快到山頂了”，他無形中成為了我的“鼓勵師”，讓我順利地寫完了這本書。
感謝為這本書做評審的專家們，他們的專業態度讓我非常感動。為了給讀者提供更多的價值，他們給我提供了大量的建議，這些建議對我的幫助非常大，讓我在后續寫作道路上更有經驗了。
感謝一直支持我的讀者們，沒有你們一路的陪伴，我會失去寫作的動力和方向。
最后我想說的是：我并不是微服務架構專家，我只是一名微服務架構的實踐者，只想把自己實踐的經驗分享給大家。由于本人學識有限，難免會有不足之處，還請讀者不吝賜教。

黃勇
2016年7月27日于上海