摘要：左傳有言民之多幸，國之不幸，當時的大多數(shù)國民視英國為蠻夷，不與商貿(mào)往來。那么，在微服務實踐過程中，哪些因素可以不必微服務呢請注意用詞，這里說的是不必，不是不要。當應用符合其中一條以上的特征時，該應用不必實行微服務。

目前業(yè)界最流行的微服務架構正在或者已被各種規(guī)模的互聯(lián)網(wǎng)公司廣泛接受和認可，業(yè)已成為互聯(lián)網(wǎng)開發(fā)人員必備技術。無論是互聯(lián)網(wǎng)、云計算還是大數(shù)據(jù)，Java平臺已成為全棧的生態(tài)體系，其重要性幾乎不可替代。

這兩年微服務作為一個非常新的技術，各種理論流派試圖從不同的角度去闡述其概念和優(yōu)勢，我一開始是拒絕的，因為我沒有”Duang“的一下想清楚。個人感性地認知是，姿勢不對，純靠意會。理性的看法則是，在思想上，那些布道師們并未達到一致。經(jīng)過參考各家思想之后，得到了一些自己的領悟，我分享給大家。

個人認為，與其說微服務是一種技術，不如將其定義為一種架構，而架構則是“技”的實現(xiàn)與“術”的策略相輔相成。“術”的策略需要分析使用場景，進行合理地劃分業(yè)務邊界，實現(xiàn)“業(yè)以類聚”，然而“技”的實現(xiàn)則通過特定的技術在實現(xiàn)業(yè)務邏輯之時，更多的考慮實現(xiàn)過程中的效率性、測試的便利性、維護的可持續(xù)性，達到“技以群分”的目的。

由此而論，我個人偏好將其定義為：“微服務是一種細粒度的SOA”。

這樣定義的好處在于，沒必要去重復地“抹黑”“單體應用”（Monolithic，也有人翻譯成“巨石應用”），緣于SOA技術的衍化過程中早已提及。那么，細粒度更多的體現(xiàn)在“取其精華，去其糟粕”。

SOA 中文定義是面向服務架構，它并非是今日的重點，請原諒我不能花大篇幅來加以闡述。我用“點到為止”的方式描述SOA具備哪些特征，以及相關的技術。

面向服務（ Service-Oriented ）

松耦合（Loose-Coupling）

模塊化（Modular）

分布式計算（Distributed Computing）

平臺無關性（Independent Platform）

集中管理（Center Government）

Web Services 技術演進的目的在于解決分布式計算中，統(tǒng)一異構系統(tǒng)的服務調(diào)用的通訊協(xié)議。前期的Web Services有XML-PRC、WSDL、SOAP等技術，不但解決了Windows平臺COM+以及Java 平臺RMI無法跨平臺的問題，而且使用了可讀性強的本文協(xié)議替代了復雜的二進制協(xié)議，如CORBA技術。現(xiàn)代的WebServices 技術主要代表有REST等。

Message Queue 技術設計的目的主要有兩個方面，從架構上來說，消息隊列服務幫助系統(tǒng)之間依賴關系解耦；從技術上來看，消息隊列為系統(tǒng)提供異步處理的能力，解決了并發(fā)同步調(diào)用導致資源消耗過集中和過快等問題，將上下游系統(tǒng)的數(shù)據(jù)結構提供了統(tǒng)一的傳輸介質。

ESB 則是 SOA 集大成實現(xiàn)。

SOA 不但不是Monolithic，而且是要解決Monolithic，Monolithic 個人偏好翻譯成“單體應用”，也被翻譯成“巨石應用”。

朋友可能覺得奇怪，故宮與“單體應用”有什么關系？故宮是帝王居住和辦公的場所，她象征著“最高權利”和“中央集權”。華夏民族，自秦朝的“三公九卿制”，還是隋朝的“三省六部制”，以及明清的“內(nèi)閣制度”，無一例外地致力于鞏固“中央集權”。

近兩千年來，雖然王朝不斷更迭，這個制度一直被沿用，并且沒有出現(xiàn)大的詬病?？墒?，1793年，英國勛爵馬戛爾尼出使中國，代表英皇為乾隆皇帝祝壽，也負有促成中英通商的使命。雖然當時的中國籠罩在“乾隆盛世”的光環(huán)下，不過在馬戛爾尼看來中國無論從科技還是社會制度上，均處于相對落后的階段。《左傳》有言：“民之多幸，國之不幸”，當時的大多數(shù)國民視英國為“蠻夷”，不與商貿(mào)往來。五十年后，中英鴉片戰(zhàn)爭爆發(fā)，1840年，中華帝國第一個不平等條約《南京條約》被迫簽訂，它不但打擊中華名族，而且“打醒”了大和民族。明治維新后的日本，屢屢挑戰(zhàn)中國的東亞地位，直到中日甲午戰(zhàn)爭失利。1895年《馬關條約》簽訂，割臺灣，賠巨款。但仍有康有為等不愿放棄，聯(lián)名千人“公車上書”，認為“中央集權”并不是問題所在。“中央集權”職責臃腫，行政不力，中央政策想要對地方面面俱到是不可能的，無法做到“因地制宜”。

我想說的是，單體應用不正像一個“中央集權”的政府嗎？而微服務應用則更像“多權分立”的“自治”政府，各個“自治”政府之間在“聯(lián)邦”的架構下“分工”和“協(xié)作”。

應用進行微服務化后，規(guī)模和體積變得更加輕量級，在編譯、打包、分發(fā)、部署等環(huán)節(jié)節(jié)約了時間，開發(fā)上效率提升。

微服務應用面向持續(xù)集成友好，自動化編譯、單元和集成測試用例執(zhí)行和回歸，提高應用整體質量。

當應用大而全時，往往牽一發(fā)而動全身，其中一個服務出現(xiàn)問題，整體受到牽動效應。整體穩(wěn)定性得不到保證，因此，經(jīng)過微服務化后，應用由原來的服務內(nèi)部組裝到服務自由組合，一旦關聯(lián)服務存在問題，整體應用可以選擇性地降級或熔斷等措施，待問題服務恢復，一切照常執(zhí)行。

微服務應用具備自動化編譯、打包、分發(fā)、部署和運維的能力。傳統(tǒng)的應用不但需要開發(fā)、還需要測試和運維人員，微服務應用實現(xiàn)后，將理想化的全棧（Full-Stack）工程師變?yōu)榭赡堋?/p> 成長的需要

微服務能夠更好，更快地適配新技術，比如目前流行的Apache Kafka。而工程人員需要接觸新的技術，為未來可能的技術選型做好準備。我的建議在一些不那么重要的微服務應用中，可以嘗試一些新的技術，在其提供的功能與實際需要之間，找到一些自己的理解，也是自我成長的需要。

論語有言：“子絕四：‘毋意、毋必、毋固、毋我’。”，簡單地說，不要臆斷，不要固執(zhí)，不要自我感覺良好，也有什么是必定的。那么，在微服務實踐過程中，哪些因素可以不必微服務呢？請注意用詞，這里說的是“不必”，不是“不要”。

當應用的場景單一時，沒有必要非得微服務，因為它本身就是微服務，例如一些靜態(tài)的通告頁面。

當應用邏輯簡單時，同樣也違背了微服務的初衷，因為微服務是為了解決復雜業(yè)務邏輯而衍生，因此這種情況下也不必實施微服務。

首先，我解釋一下“漸逝”，也就是逐漸消逝的意思。當應用所關注的業(yè)務趨于消逝狀態(tài)時，盡管有實施的空間，但無實施的必要。因為這樣的應用隨時可能不復存在，好比沒有必要去對BB機或者短信業(yè)務大張旗鼓的重構一般。

老成持重的原意是形容人做事情老練和沉穩(wěn)。這里我引用了這個成語，是為了方便記憶，需要將其拆開，多帶帶解釋。

“老”是指年老的應用，多久算得上年老呢？個人經(jīng)驗，應用服役年齡超過三年以上。

“成”則表示應用的規(guī)模已成形，業(yè)務上幾乎不再變化，比如通知應用。

“持”說明應用的場景還將持續(xù)較長時間。

“重”表示應用所處的位置舉足輕重，不能隨時重構，比如交易應用。

當應用符合其中一條以上的特征時，該應用不必實行微服務。

這一點是我最為關注，也是最擔心朋友觸犯的。我們同為工程人員，對技術的追求毋容置疑，可是千萬不能因為技術而技術，新的技術推出或是解決現(xiàn)有問題，或是提供便利性，可是也有夸大其詞的成分。理性地評估和謹慎地實施，更是我們更要關注的地方。技術困難挑戰(zhàn)聰明才智，理智對待則考驗情緒控制。

前面提到的部分是“What”和“Why”，接下來，進入“How”的部分，顧名思義，就是怎么做，如何做的意思。

怎么樣實現(xiàn)微服務，我想從以下三個方面來說明：

心態(tài)

技術

思想

當今這個浮躁的互聯(lián)網(wǎng)時代，看似科技突飛猛進，新的技術層出不窮，而實踐不力，導致首鼠兩端的心態(tài)。凡是他人掌握了新的技術，自己卻沒有，就覺得不如人，反之亦然。我想告訴大家的是，微服務并不是新的技術，而是新的思路，只不過咨詢發(fā)達，加上基礎的沉淀，讓老的技術或理論在新的時代能夠“飛入尋常百姓家”。

當微服務被廣泛地被業(yè)界認可和接受時，或許你總會擔心在何處實踐，因此，在心態(tài)上，需要做到不要擔心它花落誰家，更要放平心態(tài)，思考它為什么存在的理由。

當你或你的團隊在推廣微服務過程中，你得首先做好被挑戰(zhàn)甚至是攻擊的準備，據(jù)不完全統(tǒng)計，世界上有5%的人，是因為反對而反對的人。但是反對負面情緒可能會印象其他50%的人。由此前提之后，還需具備攻擊“異端邪說”的能力，這樣就能達到“斯害也已”（這種危害也可以被消滅）。

最后一種心態(tài)則是不要怕犯錯，錯了不要忌憚改正。作為工程人員，實施的過程中不出錯是不可能的，除非不去做。不要畏懼犯錯，犯錯也是更好地縮小內(nèi)心期望和現(xiàn)實情況的鴻溝，不犯錯就沒有成長的空間，因此，不怕錯，也不忌改正。

前面的部分用了不少詩詞，接下來就不會那么“詩”了，來點“干”的，也是今天的技術重頭戲。馬上進入技術的部分。

技術上，基本上也是以下三個套路：

Docker

DDD

Middleware（Java）

DDD是Domain Driven Design（領域驅動設計）的簡寫，該技術源于Eric Evans 在其名著《Domain Driven Design》。從年代來看，已是相當老的設計方法論了。它作為微服務重要的理論依據(jù)，如今又如“鳳凰涅槃”一般，重新進入軟件領域的視野。DDD的三大實施策略在具體微服務實踐過程中，取二舍一。當然，整個DDD的理論并不限于此，個人理解，DDD好像是一個傳說，大家都聽說過，但是誰也沒有見到過。而是實現(xiàn)這種理想就如同烏托邦式的“共產(chǎn)主義”，目前仍未到時候。

有界上下文的思想，個人認為是在《設計模式》中的“單職責原則”進一步發(fā)展而言。其實也體現(xiàn)了東西方文化的差異，東方是以古代中國為代表的“中央集權”思想，和古希臘城邦的“三權分立”的民治思想。微服務則屬于“權力分立”思想的范疇。在微服務實踐過程中，確定應用邊界是必要的，也是困難的。必要性反應在系統(tǒng)職責劃分，要簡約、清晰，不耦合。困難性則體現(xiàn)在重構過程不是一蹴而就，而是循序漸進，同時，應用還伴隨著業(yè)務發(fā)展而同步開發(fā)，其間的困難是可預知的。雖然過程是痛苦的，但是也不得不去做。

持續(xù)集成是繼承了TDD（Test Driven Development，測試驅動開發(fā)）的思想，對應形成規(guī)模的公司而言，基本上都部署了持續(xù)集成的環(huán)境，在阿里則是Aone 系統(tǒng)來統(tǒng)籌。一些流行的開源軟件，如GitLab、Jenkins（Hudson）等。

以上兩個策略均在實踐中被采納，那么上下文映射（Context Map）則被舍棄，舍棄的原因并不在于其不合理，而是難以駕馭。例如，用戶服務提供用戶的模型，其中包括了姓名、生日、電話等?？墒窍掠蜗到y(tǒng)，需要僅僅需要用戶的姓名信息，而實際情況，用戶服務無法提供這么細粒度的服務，那么不得不在中間做一層上下文映射，將兩者不再直接關聯(lián)。這種情況貌似還看不出端倪，可是為服務化后，服務數(shù)量眾多，其映射環(huán)節(jié)基本上不可控制，下游系統(tǒng)配合改動也是代價頗高，因此，在實踐過程中，還是保持原有的調(diào)用關系。盡量做到改造過程中，減低錯誤率。

中間件是微服務實施過程中不可或缺的一個環(huán)節(jié)，實現(xiàn)中間件的編程語言可以任意，不過目前市場上最為流行還屬Java。經(jīng)剛才粗略的統(tǒng)計，在座的朋友們從事Java居多，本人恰好也相對熟悉這個領域。接下來，我們一同來探討，Java 中間件在微服務實踐過程中的措施。由于時間的關系，無法做到一一列舉，因此，以下每個小節(jié)均有實例說明。

Spring

Spring Boot

Spring Cloud

Spring Cloud Stream

Spring Boot DevOps

在微服務實踐的過程中，中間件部門向各條業(yè)務線的開發(fā)推廣，用Annotation驅動的方式替代過去XML配置的方式：

Annotation驅動方式

在Spring 3.1 以及更好的版本中，提供了大量的Annotation作為XML配置的替代一下方式（現(xiàn)場統(tǒng)計，基本上沒有人知道這種方式）：

XML配置方式

工程人員相對XML的方式更為熟悉，以上XML配置了是Spring WebMVC的一些組件Bean。實際上，除了@EnableWebMvc以外，還提供了很多@EnableXXX的替代方式，例如@EnableAsync、@EnableAspectJAutoProxy等。在實施過程中，很多開發(fā)人員錯誤的認為這些是Spring Boot的帶來的便利，其實不然。

在Spring Boot 推廣實施過程中，除了以上Annotation重構方式以外，我想在前端渲染引擎選型評估方面談談自己的心得和體會，建議大家時刻保持懷疑的態(tài)度，一家之言，僅供參考。

Thymeleaf（Spring 推薦）

優(yōu)點

HTML結構化

UI友好

Thymeleaf 設計初衷就是針對UI友好，讓開發(fā)人員在編輯模板頁面時，遵循標準HTML結構。
表達式功能強大

表達式功能強大
不但兼容標準 OGNL 表達式，而且也支持Spring 表達。Spring 表達式為Spring 3 之后推出的重要功能提供動態(tài)的執(zhí)行程序的能力。

缺點

編碼略微繁瑣

沒有比較不存在優(yōu)劣，Thymeleaf 在編輯過程中相對繁瑣，相比較于Velocity和JSP而言。

性能一般

最明顯的缺點是，性能著實一般，因此，不建議用在訪問過頻繁的頁面，比如寶貝詳情頁面。

擴展復雜

Thymeleaf 元素標簽相對比較復雜。

Velocity（廣泛應用）

優(yōu)點

性能良好

相比較于 Thymeleaf 而言，Velocity的性能良好。

易于擴展

在擴展性方面，Velocity提供宏（Marco）擴展，實現(xiàn)代碼復用。

事件處理

開發(fā)人員可能對于事件處理上相對陌生，我簡單地介紹以下，Velocity 提"org.apache.velocity.app.event.EventHandler"接口，其中典型代表為："org.apache.velocity.app.event.ReferenceInsertionEventHandler”接口，主要用于攔截引用插入前的事件。

配置靈活

也是Velocity顯著特點，提供了大量靈活的配置項，方便開發(fā)人員設置，例如配置模板位置、字符編碼等。

缺點

HTML結構化不友好

由于Velocity模板的語法特點并非HTML結構化友好，指令（Directive）以及宏（Marco）均直接在頁面非標簽區(qū)域植入，比如 #set 這種寫法。

發(fā)展停滯

Velocity 1.7 版本自2010年以來，不再更新，因此，Spring 4.3 版本（或者Spring Boot 1.4）開始，將Velocity支持標記為Deprecated。

JSP（Java EE標準）

優(yōu)點：

編碼靈活

較以上兩種模板引擎，JSP編碼方式更為靈活，其中包括：

Scriptlets

早期類PHP腳本語法，即在JSP頁面中直接添加 Java 代碼，這種編程模式稱為 Scriptlets ，其對應的J2EE（當時還稱作J2EE，即現(xiàn)在的Java EE）設計模型為Model 1。

EL（Express Language）

由于Scriptlets編程模式在頁面上植入太多的 Java 代碼，代碼既難以復用，維護成本又相當巨大。JSP 2.0 規(guī)范引入了EL（Express Language）1.0 規(guī)范，隨后該能力被用在J2EE設計模式中，逐步發(fā)展成 Model 2 以及 MVC ，JSP頁面不再負責數(shù)據(jù)組裝等邏輯，而是僅承載頁面渲染的作用（當然還是具備 Scriptlets 能力，只是不推薦使用這種方式）。

兼容性好

JSP屬于Java EE規(guī)范，因此Java EE均提供了實現(xiàn)，比如 Tomcat、Jetty、WebLogic 等等。因此，JSP 具備天然性兼容，不需要額外引入其他資源。

性能優(yōu)秀

JSP屬于解釋編譯型模板語言，無論是 Scriptlets 還是 EL 均可以翻譯成 Java 源文件，然后將 Java 源文件編譯成 Java Class 文件，再經(jīng)過容器加載并且執(zhí)行相關方法調(diào)用（可參考org.apache.jasper.servlet.JspServlet）。

多種頁面結構化

這個特點是很多國內(nèi) Java 工程人員不太關注的特性，通常將JSP頁面結構定格在HTML，實際上，它的頁面結構格式可以設置成更為嚴格的XHTML，甚至是XML。順便提一句，Thymeleaf 也具備該能力，而 Velocity 不具備。因此，在我看來，JSP 并不是太落伍，而是太超前。

缺點：

限制表達式（EL）

EL 的實現(xiàn)是OGNL 表達式的子集，僅實現(xiàn)了簡單地數(shù)據(jù)讀取和邏輯運行。類似于 Bean 方法調(diào)用這樣的高級語法，需要配合 JSF 這樣的Web技術來配合（ JSF 叫座不叫好的 Web 框架 ）。

擴展繁瑣

JSP 擴展主要是JSP 標簽擴展，JSP 標簽擴展被很多人視為反模式，我倒不怎么認為，但是對其配置上倒是頗為復雜，舉個例子，每個 Tag 的屬性需要綁定一個對應的實現(xiàn)類屬性，并且類型復雜，功能各異，比如 IterationTag 和 BodyTag 的作用存在一定的區(qū)別。

規(guī)約較多

JSP 除了tag lib的規(guī)約以外，還有jsp-property-group 等，我用一段web.xml中的配置為例：

    
        http://tae-sdk.taobao.com/taglibs/sdk
        /META-INF/config/taglibs/sdk-web-1.0.tld
    
    
        *.jsp
        GBK
        /WEB-INF/jsp/coda/footer.jspf
        true
    
 

Servlet強依賴

JSP 對于 Servlet API 是強依賴的，主要執(zhí)行邏輯與Servlet 相同（ init 方法、service 方法以及 destroy 方法 ），在現(xiàn)代化的Java Web 編程模式中，基本上屏蔽了Servlet API接口，比如 Spring WebMVC 中的@RequestParam 用于獲取請求參數(shù)，去取代Servlet API中的 javax.servlet.http.HttpServletRequest#getParameter(String) 方法，因為該方法僅返回 String 類型，如要轉化成 Integer 類型，不得不調(diào)用 Integer#valueOf(String) 方法進行轉化。再則，目前流行的HTTP 2 Web服務器 - Undertow 并不兼容 Servlet API 方案。

接下來，進入Spring Cloud的部分。

Spring Cloud 官方提供了基本功能描述，其中包括：

分布式/版本化配置（Distributed/versioned configuration）

注冊與發(fā)現(xiàn)（Registry and Discovery）

路由（Routing）

服務調(diào)用（Service-to-service calls）

負載均衡（Load balancing）

短路（ Circuit Break ）

分布式消息（Distributed messaging）

在Martin Fowler的名著《Enterprise Integration Patterns》（企業(yè)整合模式 ）中提到過（Channel）的概念，Spring Cloud Stream 付諸于實踐，提供抽象實現(xiàn)。這種抽象實現(xiàn)的好處在于對應用透明，應用不再強制綁定在某種具體技術上，對它而言，Spring Cloud Stream 為其建立管道（Channel），其中有兩個概念被涉及：

Source（發(fā)送端）

Sink（接收端）

筆者已在SF平臺發(fā)起了 “Java 微服務實踐”為系列課程，內(nèi)容包括目前最流行技術，分為 Spring Boot、Spring Cloud、Spring Cloud Stream 等系列，其目的希望能夠幫助初學者深入淺出地掌握，同時更希望為高階從業(yè)人員起到拋磚引玉的作用。

感興趣的朋友，請點擊鏈接：Java 微服務實踐系列課堂

微博：@mercyblitz

郵箱：[email protected]