Java 微服務實踐

mercyblitz發表於2017-06-22

楔子

目前業界最流行的微服務架構正在或者已被各種規模的網際網路公司廣泛接受和認可，業已成為網際網路開發人員必備技術。無論是網際網路、雲端計算還是大資料，Java平臺已成為全棧的生態體系，其重要性幾乎不可替代。

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

微服務是什麼？

微服務是一種細粒度（Fine-Grain）的SOA

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

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

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

SOA又是什麼?

SOA = Service-Oriented Architecture

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

SOA有什麼?

特徵

面向服務（ Service-Oriented ）
鬆耦合（Loose-Coupling）
模組化（Modular）
分散式計算（Distributed Computing）
平臺無關性（Independent Platform）
集中管理（Center Government）

技術

Web Services

Web Services 技術演進的目的在於解決分散式計算中，統一異構系統的服務呼叫的通訊協議。前期的Web Services有XML-PRC、WSDL、SOAP等技術，不但解決了Windows平臺COM+以及Java 平臺RMI無法跨平臺的問題，而且使用了可讀性強的本文協議替代了複雜的二進位制協議，如CORBA技術。現代的WebServices 技術主要代表有REST等。

Message Queue

Message Queue 技術設計的目的主要有兩個方面，從架構上來說，訊息佇列服務幫助系統之間依賴關係解耦；從技術上來看，訊息佇列為系統提供非同步處理的能力，解決了併發同步呼叫導致資源消耗過集中和過快等問題，將上下游系統的資料結構提供了統一的傳輸介質。

ESB

ESB 則是 SOA 集大成實現。

SOA不是什麼?

SOA ≠ Monolithic

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

Monolithic是什麼?

故宮

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

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

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

為什麼要微服務？

效率的需要

應用進行微服務化後，規模和體積變得更加輕量級，在編譯、打包、分發、部署等環節節約了時間，開發上效率提升。

質量的需要

微服務應用面向持續整合友好，自動化編譯、單元和整合測試用例執行和迴歸，提高應用整體質量。

穩定的需要

當應用大而全時，往往牽一髮而動全身，其中一個服務出現問題，整體受到牽動效應。整體穩定性得不到保證，因此，經過微服務化後，應用由原來的服務內部組裝到服務自由組合，一旦關聯服務存在問題，整體應用可以選擇性地降級或熔斷等措施，待問題服務恢復，一切照常執行。

運維的需要

微服務應用具備自動化編譯、打包、分發、部署和運維的能力。傳統的應用不但需要開發、還需要測試和運維人員，微服務應用實現後，將理想化的全棧（Full-Stack）工程師變為可能。

成長的需要

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

為什麼不必微服務？

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

場景單一

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

邏輯簡單

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

業務漸逝

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

“老成持重”

老成持重的原意是形容人做事情老練和沉穩。這裡我引用了這個成語，是為了方便記憶，需要將其拆開，單獨解釋。

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

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

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

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

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

技術盲從

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

怎麼實現微服務

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

怎麼樣實現微服務，我想從以下三個方面來說明：

心態
技術
思想

心態

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

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

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

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

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

技術

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

Docker
DDD
Middleware（Java）

DDD

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

有界上下文（Bounded Context）

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

持續整合（Continuous integration）

持續整合是繼承了TDD（Test Driven Development，測試驅動開發）的思想，對應形成規模的公司而言，基本上都部署了持續整合的環境，在阿里則是Aone 系統來統籌。一些流行的開源軟體，如GitLab、Jenkins（Hudson）等。

上下文對映（Context Map）

以上兩個策略均在實踐中被採納，那麼上下文對映（Context Map）則被捨棄，捨棄的原因並不在於其不合理，而是難以駕馭。例如，使用者服務提供使用者的模型，其中包括了姓名、生日、電話等。可是下游系統，需要僅僅需要使用者的姓名資訊，而實際情況，使用者服務無法提供這麼細粒度的服務，那麼不得不在中間做一層上下文對映，將兩者不再直接關聯。這種情況貌似還看不出端倪，可是為服務化後，服務數量眾多，其對映環節基本上不可控制，下游系統配合改動也是代價頗高，因此，在實踐過程中，還是保持原有的呼叫關係。儘量做到改造過程中，減低錯誤率。

Middleware

中介軟體是微服務實施過程中不可或缺的一個環節，實現中介軟體的程式語言可以任意，不過目前市場上最為流行還屬Java。經剛才粗略的統計，在座的朋友們從事Java居多，本人恰好也相對熟悉這個領域。接下來，我們一同來探討，Java 中介軟體在微服務實踐過程中的措施。由於時間的關係，無法做到一一列舉，因此，以下每個小節均有例項說明。

Spring
Spring Boot
Spring Cloud
Spring Cloud Stream
Spring Boot DevOps

Spring

Annotation驅動

在微服務實踐的過程中，中介軟體部門向各條業務線的開發推廣，用Annotation驅動的方式替代過去XML配置的方式：

Annotation驅動方式

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

XML配置方式

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

Spring Boot

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

渲染引擎

Thymeleaf（Spring 推薦）

優點

HTML結構化
UI友好

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

表示式功能強大
不但相容標準 OGNL 表示式，而且也支援Spring 表達。Spring 表示式為Spring 3 之後推出的重要功能提供動態的執行程式的能力。

缺點

編碼略微繁瑣

沒有比較不存在優劣，Thymeleaf 在編輯過程中相對繁瑣，相比較於Velocity和JSP而言。

效能一般

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

擴充套件複雜

Thymeleaf 元素標籤相對比較複雜。

Velocity（廣泛應用）

優點

效能良好

相比較於 Thymeleaf 而言，Velocity的效能良好。

易於擴充套件

在擴充套件性方面，Velocity提供巨集（Marco）擴充套件，實現程式碼複用。

事件處理

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

配置靈活

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

缺點

HTML結構化不友好

由於Velocity模板的語法特點並非HTML結構化友好，指令（Directive）以及巨集（Marco）均直接在頁面非標籤區域植入，比如 #set 這種寫法。

發展停滯

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

JSP（Java EE標準）

優點：

編碼靈活

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

Scriptlets

早期類PHP指令碼語法，即在JSP頁面中直接新增 Java 程式碼，這種程式設計模式稱為 Scriptlets ，其對應的J2EE（當時還稱作J2EE，即現在的Java EE）設計模型為Model 1。

EL（Express Language）

由於Scriptlets程式設計模式在頁面上植入太多的 Java 程式碼，程式碼既難以複用，維護成本又相當巨大。JSP 2.0 規範引入了EL（Express Language）1.0 規範，隨後該能力被用在J2EE設計模式中，逐步發展成 Model 2 以及 MVC ，JSP頁面不再負責資料組裝等邏輯，而是僅承載頁面渲染的作用（當然還是具備 Scriptlets 能力，只是不推薦使用這種方式）。

相容性好

JSP屬於Java EE規範，因此Java EE均提供了實現，比如 Tomcat、Jetty、WebLogic 等等。因此，JSP 具備天然性相容，不需要額外引入其他資源。
效能優秀

JSP屬於解釋編譯型模板語言，無論是 Scriptlets 還是 EL 均可以翻譯成 Java 原始檔，然後將 Java 原始檔編譯成 Java Class 檔案，再經過容器載入並且執行相關方法呼叫（可參考org.apache.jasper.servlet.JspServlet）。
多種頁面結構化

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

缺點：

限制表示式（EL）

EL 的實現是OGNL 表示式的子集，僅實現了簡單地資料讀取和邏輯執行。類似於 Bean 方法呼叫這樣的高階語法，需要配合 JSF 這樣的Web技術來配合（ JSF 叫座不叫好的 Web 框架）。

擴充套件繁瑣

JSP 擴充套件主要是JSP 標籤擴充套件，JSP 標籤擴充套件被很多人視為反模式，我倒不怎麼認為，但是對其配置上倒是頗為複雜，舉個例子，每個 Tag 的屬性需要繫結一個對應的實現類屬性，並且型別複雜，功能各異，比如 IterationTag 和 BodyTag 的作用存在一定的區別。

規約較多

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

<jsp-config>
    <taglib>
        <taglib-uri>http://tae-sdk.taobao.com/taglibs/sdk</taglib-uri>
        <taglib-location>/META-INF/config/taglibs/sdk-web-1.0.tld</taglib-location>
    </taglib>
    <jsp-property-group>
        <url-pattern>*.jsp</url-pattern>
        <page-encoding>GBK</page-encoding>
        <include-coda>/WEB-INF/jsp/coda/footer.jspf</include-coda>
        <trim-directive-whitespaces>true</trim-directive-whitespaces>
    </jsp-property-group>
</jsp-config>

Servlet強依賴

JSP 對於 Servlet API 是強依賴的，主要執行邏輯與Servlet 相同（ init 方法、service 方法以及 destroy 方法），在現代化的Java Web 程式設計模式中，基本上遮蔽了Servlet API介面，比如 Spring WebMVC 中的@RequestParam 用於獲取請求引數，去取代Servlet API中的 javax.servlet.http.HttpServletRequest#getParameter(String) 方法，因為該方法僅返回 String 型別，如要轉化成 Integer 型別，不得不呼叫 Integer#valueOf(String) 方法進行轉化。再則，目前流行的HTTP 2 Web伺服器 – Undertow 並不相容 Servlet API 方案。

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

Spring Cloud

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

分散式/版本化配置（Distributed/versioned configuration）
註冊與發現（Registry and Discovery）
路由（Routing）
服務呼叫（Service-to-service calls）
負載均衡（Load balancing）
短路（ Circuit Break ）
分散式訊息（Distributed messaging）

Spring Cloud Stream

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

Source（傳送端）
Sink（接收端）

技術交流

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

感興趣的朋友，請點選連結：Java 微服務實踐系列課堂