微服務(wù)架構(gòu)與實(shí)踐摘要

一、微服務(wù)架構(gòu)圖：

二、技術(shù)介紹：

三、為什么選擇微服務(wù)架構(gòu)

首先，當(dāng)然是該套架構(gòu)方法有著名的成功經(jīng)驗(yàn)才導(dǎo)致大家去了解與學(xué)習(xí)它。

微服務(wù)架構(gòu)中的 “微” 體現(xiàn)了其核心要素，即服務(wù)的微型化，就是每個(gè)服務(wù)微小到只需專注做好一件事。這件事緊密圍繞業(yè)務(wù)領(lǐng)域，形成高度內(nèi)聚的自治性。

一些大型應(yīng)用系統(tǒng)，采用模塊化的分層式架構(gòu)，所有的業(yè)務(wù)邏輯代碼最終會(huì)打進(jìn)一個(gè)代碼庫(kù)中統(tǒng)一部署。這種應(yīng)用架構(gòu)的問題是，全部開發(fā)人員會(huì)共享一個(gè)代碼庫(kù)，不同模塊的邊界模糊，實(shí)現(xiàn)高內(nèi)聚、松耦合極其困難。如果你接手過這類應(yīng)用的遺留系統(tǒng)，嘗試去做重構(gòu)改進(jìn)時(shí)，肯定碰到過這類場(chǎng)景，改了一個(gè)地方好幾個(gè)其他模塊也需要同步改動(dòng)，模塊的邊界輕易被穿透，這種應(yīng)用的架構(gòu)有一個(gè)很形象的名字叫 “洋蔥架構(gòu)”，洋蔥的特點(diǎn)就是一層又一層的粘連，重構(gòu)這樣的系統(tǒng)就像切洋蔥一樣讓人忍不住飆淚。

微服務(wù)架構(gòu)強(qiáng)調(diào) “微”，但之前有些采用了 SOA 服務(wù)化架構(gòu)思想的系統(tǒng)會(huì)搞出很多胖服務(wù)來，一點(diǎn)也不微，這依然帶來耦合。

這一點(diǎn)只能依賴系統(tǒng)架構(gòu)師的服務(wù)化建模能力了，但微服務(wù)架構(gòu)強(qiáng)調(diào)每個(gè)服務(wù)一個(gè)進(jìn)程，使用進(jìn)程為邊界來隔離代碼庫(kù)至少讓同一應(yīng)用系統(tǒng)不同層次的開發(fā)人員享有自己完全自治的領(lǐng)地，每個(gè)微服務(wù)都有一個(gè)掌控者。從某種程度上讓不小心做錯(cuò)事，例如：跨出服務(wù)邊界的代碼耦合依賴，變得沒那么容易。

一個(gè) 20 人的團(tuán)隊(duì)維護(hù)一個(gè) 40 萬行共享代碼庫(kù)的單一應(yīng)用，在里面修改 bug 和添加功能都將十分困難。

有一篇文章 《程序員的成長(zhǎng)和代碼行數(shù)的關(guān)系》 里提到大部分普通程序員成長(zhǎng)生涯的瓶頸在 2 萬行代碼左右，

超過這個(gè)代碼行數(shù)的應(yīng)用系統(tǒng)維護(hù)起來將倍感吃力，所以我們系統(tǒng)這兩年的高速發(fā)展膨脹，已讓團(tuán)隊(duì)維護(hù)起來倍感吃力了。

所以我們想要把一個(gè)大系統(tǒng)拆分成許多不同的微服務(wù)，每個(gè)微服務(wù)的規(guī)模大小控制在一個(gè)普通程序員的舒適維護(hù)區(qū)能力范圍內(nèi)。

微服務(wù)架構(gòu)實(shí)施

把 1 個(gè)應(yīng)用進(jìn)程部署到 1 臺(tái)主機(jī)，部署復(fù)雜度是 1 x 1 = 1，我們有 200 臺(tái)主機(jī)，那么部署復(fù)雜度是 1 x 200 = 200。

把 1 個(gè)應(yīng)用進(jìn)程拆分成了 50 個(gè)微服務(wù)進(jìn)程，則部署復(fù)雜度變成了 50 x 200 = 10000。

部署變得復(fù)雜和麻煩多了，同時(shí)監(jiān)控的進(jìn)程數(shù)也大幅增加，監(jiān)控的復(fù)雜度也上升了很多。所以實(shí)施微服務(wù)架構(gòu)是有很高成本的，只有系統(tǒng)的規(guī)模到了一定程度才適合，這也是為什么微服務(wù)架構(gòu)實(shí)踐誕生于大型互聯(lián)網(wǎng)公司。

微服務(wù)推崇一切自動(dòng)化的文化，這也是因?yàn)槠溥\(yùn)維復(fù)雜度的乘數(shù)級(jí)飆升，從開發(fā)之后的構(gòu)建、測(cè)試、部署都需要一個(gè)高度自動(dòng)化的環(huán)境來支撐才能有效降低邊際成本。

《Building Microservices》一書對(duì)實(shí)施微服務(wù)架構(gòu)有系統(tǒng)性的描述和很多業(yè)界案例的簡(jiǎn)單引用描述，這里不展開講實(shí)施細(xì)節(jié)，那樣就太長(zhǎng)了。

我們這里簡(jiǎn)單總結(jié)下實(shí)施的要點(diǎn)：

自動(dòng)化文化與環(huán)境：自動(dòng)構(gòu)建、自動(dòng)測(cè)試、自動(dòng)部署。

圍繞業(yè)務(wù)能力建模服務(wù)，松耦合、高內(nèi)聚、暴露接口而隱藏實(shí)現(xiàn)細(xì)節(jié)。

服務(wù)協(xié)作模型：中心化（樂隊(duì)模型：中心指揮）和去中心化（舞蹈模型：群舞自組織），各自場(chǎng)景不同。

服務(wù)交互方式：RPC/REST/WS 技術(shù)很多但考慮統(tǒng)一。

服務(wù)部署的獨(dú)立性、失敗隔離性、可監(jiān)控性。

服務(wù)流控：降級(jí)、限流

服務(wù)恢復(fù)：多考慮故障發(fā)生如何快速恢復(fù)而非如何避免發(fā)生故障。

服務(wù)發(fā)布：灰度。

服務(wù)部署：一服務(wù)一主機(jī)模型，需要虛擬化（Hypervisor）、容器化（LXC， Docker）等技術(shù)支持，實(shí)現(xiàn)硬件資源隔離。

服務(wù)配置：中心化配置服務(wù)支持

康威定律：任何設(shè)計(jì)系統(tǒng)的組織，最終產(chǎn)生的設(shè)計(jì)等同于組織之內(nèi)、之間的溝通結(jié)構(gòu)。系統(tǒng)架構(gòu)的設(shè)計(jì)符合組織溝通結(jié)構(gòu)取得的收益最大。

伯斯塔爾法則：服務(wù)健壯性原則 —— 發(fā)送時(shí)要保守，接收時(shí)要開放。

自進(jìn)化的微服務(wù)架構(gòu)

早期人們把軟件開發(fā)和建筑學(xué)作類比，Architect 這個(gè)詞來就源于建筑學(xué)，但軟件產(chǎn)品和建筑物的性質(zhì)完全不同。建筑物本身一旦建成則幾無變化了，唯有老化后被替代了。軟件系統(tǒng)會(huì)在其生命周期中不斷變化，唯一不變的就是變化，擁抱變化，需用進(jìn)化的觀點(diǎn)看待架構(gòu)演進(jìn)。與此類似的是城市，城市的演進(jìn)發(fā)展總是漸進(jìn)式的，我們不會(huì)在一座舊城旁建一座新城，然后把舊城的居民遷到新城然后再把舊城廢棄了。但經(jīng)常我們會(huì)用這樣的方法重寫一個(gè)新系統(tǒng)并替換掉舊系統(tǒng)，付出高昂的成本。

而微服務(wù)架構(gòu)思路是不鼓勵(lì)這種方式的，系統(tǒng)的演進(jìn)是通過局部的新增、改進(jìn)或替換微服務(wù)來實(shí)現(xiàn)的。而微服務(wù)本身的變化周期是不同步的，從整體上就形成了一種漸進(jìn)式的、符合自然進(jìn)化的系統(tǒng)演進(jìn)道路。所以 Architect（架構(gòu)師）更像是城市規(guī)劃師而非建筑師，對(duì)軟件系統(tǒng)進(jìn)行類似城市劃分區(qū)域的規(guī)劃。

從常識(shí)上我們知道把學(xué)校和住宅放在一個(gè)區(qū)域內(nèi)是合理的，但如果再放一個(gè)垃圾處理廠則不合理。學(xué)校和住宅就是提供兩種不同能力的服務(wù)，垃圾處理廠是另一種服務(wù)，但現(xiàn)實(shí)中軟件系統(tǒng)的規(guī)劃其實(shí)不像城市規(guī)劃那么有常識(shí)性，這是架構(gòu)師能力和經(jīng)驗(yàn)發(fā)揮作用的地方，前期規(guī)劃的不合理會(huì)在后期帶來維護(hù)成本的放大。

每個(gè)歷史悠久的城市都有各自不同的味道，城市中的人、時(shí)間、技術(shù)進(jìn)步共同決定了今天城市的面貌。微服務(wù)架構(gòu)的妙處就在于它符合城市歷史演進(jìn)規(guī)律，隨著人員變化、時(shí)間、技術(shù)改進(jìn)而引發(fā)自然漸進(jìn)式的進(jìn)化。

微服務(wù)架構(gòu)與架構(gòu)師

架構(gòu)師的一個(gè)角色是技術(shù)決策者，技術(shù)決策涉及很多權(quán)衡取舍（trade-off），而微服務(wù)架構(gòu)給了架構(gòu)師更多權(quán)衡取舍的空間。

每個(gè)微服務(wù)實(shí)現(xiàn)層面的技術(shù)決策更多由服務(wù)負(fù)責(zé)人決定，服務(wù)的分拆伴隨著決策權(quán)和責(zé)任的分拆，這也減輕了整體應(yīng)用負(fù)責(zé)人的責(zé)任負(fù)擔(dān)。

架構(gòu)師解放出來從整體和全局上將更加關(guān)注服務(wù)之間是如何交互，并確保能正確的監(jiān)控系統(tǒng)全局的健康性。

分拆了服務(wù)實(shí)現(xiàn)的技術(shù)決策權(quán)，那何時(shí)又該適當(dāng)?shù)慕槿胍员苊夥?wù)實(shí)現(xiàn)不當(dāng)危及整體系統(tǒng)的安全？

就像教孩子騎車，你無法代替它們?nèi)ヲT，你小心的看著他們騎的歪歪扭扭，擔(dān)心他們摔倒。事實(shí)上，孩子騎車摔倒的次數(shù)比你擔(dān)心的要少，但如果每次快摔倒時(shí)都去扶住，那么他們也許永遠(yuǎn)學(xué)不會(huì)騎車。當(dāng)孩子騎車失控時(shí)沖向了繁忙的馬路或要沖下路邊的深溝，那時(shí)才有必要介入去穩(wěn)住他們。

架構(gòu)師工作在抽象和具體兩個(gè)層面：

架構(gòu)是一項(xiàng)技術(shù)工作，技術(shù)工作要服務(wù)于組織的戰(zhàn)略目標(biāo)。大量的工程實(shí)踐在每日的工作中不斷變化，而漸漸穩(wěn)定的實(shí)踐方式被抽象提煉為一系列原則。原則的普及帶來整體效率的提升和邊際成本的下降，以更有效的支持組織戰(zhàn)略目標(biāo)的快速達(dá)成。另外也要確保這些原則不是讓開發(fā)人員的生活變得更凄慘而是更美好。跟蹤新技術(shù)發(fā)展確保能在合適的時(shí)候做出正確的取舍折衷。讓開發(fā)人員理解某項(xiàng)技術(shù)決策的影響和制約以便最有效的執(zhí)行，甚至在特定情形下深入到代碼的實(shí)現(xiàn)層面。

文章開頭說了，這是我們實(shí)施系統(tǒng)的第四個(gè)大版本，而之前每一個(gè)大版本升級(jí)都是一次舊城倒新城的整體搬遷。而微服務(wù)架構(gòu)天然的自然進(jìn)化屬性是否預(yù)示著這應(yīng)該是最后一個(gè)大版本升級(jí)了？微服務(wù)架構(gòu)述說著沒有永恒的架構(gòu)，只有進(jìn)化的架構(gòu)，但微服務(wù)架構(gòu)不是銀彈，也沒有銀彈。

1. 單塊架構(gòu)及其面臨的挑戰(zhàn)

1.1 三層架構(gòu)

三層架構(gòu)包括表示層、業(yè)務(wù)邏輯層、數(shù)據(jù)訪問層。

1.2 單塊架構(gòu)

所有的功能在一個(gè)工程項(xiàng)目中。

單塊架構(gòu)常見的架

1.3 互聯(lián)網(wǎng)產(chǎn)品特性

創(chuàng)新成本低、需求變化快、用戶群里龐大。單塊架構(gòu)無法滿足。

2.微服務(wù)架構(gòu)綜述

2.1 什么是微服務(wù)

微服務(wù)架構(gòu)模型（Microservice Architect Pattern）

引用下當(dāng)今世界軟件開發(fā)領(lǐng)域最具影響力的五位大師之一的定義：

微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間 互相協(xié)調(diào)、互相配合 ，為用戶提供最終價(jià)值。每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)于服務(wù)間采用輕量級(jí)的通信機(jī)制互相溝通（通常是基于HTTP的RESTful API）。每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應(yīng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機(jī)制，對(duì)具體的一個(gè)服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語言、工具對(duì)其進(jìn)行構(gòu)建。 —摘自 馬丁·福勒先生的博客

2.1.1 多微才夠微

微服務(wù)架構(gòu)通過對(duì)特定業(yè)務(wù)領(lǐng)域的分析與建模，將復(fù)雜的應(yīng)用分解成為小而專一、耦合度低并且高度自治的一組服務(wù)。

代碼行數(shù)和開發(fā)時(shí)間都不能衡量是否”微”的重要因素。

“微”所表達(dá)的是一種設(shè)計(jì)思想和指導(dǎo)方針，是團(tuán)隊(duì)或組織共同努力找到的一個(gè)平衡點(diǎn)。仁者見仁智者見智，但要遵循如下2點(diǎn)：

業(yè)務(wù)獨(dú)立性： 保證微服務(wù)具有業(yè)務(wù)獨(dú)立性的單元，如：

業(yè)務(wù)： 訂單，產(chǎn)品，合同

功能：發(fā)送郵件，單點(diǎn)登錄驗(yàn)證，數(shù)據(jù)庫(kù)同步

團(tuán)隊(duì)自主性： 考慮團(tuán)隊(duì)的溝通及寫作成本，一般建議不超過十人。

2.1.2 單一職責(zé)

高內(nèi)聚：一個(gè)模塊各個(gè)元素彼此結(jié)合的緊密度高。

低耦合：對(duì)于一個(gè)完整的系統(tǒng)，模塊與模塊之間，盡可能的獨(dú)立存在。

SRP ：（Single Responsibility Principle，單一職責(zé)原則）：即一個(gè)對(duì)象應(yīng)該只有一個(gè)發(fā)生變化的原因，如果一個(gè)對(duì)象可被多個(gè)原因改變，那么說明這個(gè)對(duì)象承擔(dān)了多個(gè)職責(zé)。

### 2.1.2 輕量級(jí)通信

服務(wù)之間應(yīng)通過輕量級(jí)的通信機(jī)制，實(shí)現(xiàn)彼此間的互通互聯(lián)，互相協(xié)作。

格式： XML，JSON

協(xié)議： HTTP，REST（Representational State Transfer，表述性狀態(tài)傳遞）

2.1.3 獨(dú)立性

交付過程中，開發(fā)，測(cè)試以及部署的獨(dú)立性。改變某個(gè)服務(wù)時(shí)，對(duì)其它服務(wù)不產(chǎn)生影響。

2.1.4 進(jìn)程隔離

理論上，多個(gè)服務(wù)部署到一個(gè)節(jié)點(diǎn)上，并且能運(yùn)行在不同的進(jìn)程中，且互不影響，但是不推薦這么做。

因?yàn)樵黾恿瞬渴鸷蛿U(kuò)展的復(fù)雜度，建議還是一個(gè)服務(wù)一個(gè)節(jié)點(diǎn)。

總結(jié)： 微服務(wù)架構(gòu)就是將單一的應(yīng)用程序劃分為一組小的服務(wù)，每個(gè)服務(wù)都是具有業(yè)務(wù)屬性的獨(dú)立單元，同時(shí)能夠被獨(dú)立開發(fā)，獨(dú)立運(yùn)行，獨(dú)立測(cè)試以及獨(dú)立部署。

2.2 微服務(wù)的誕生背景

互聯(lián)網(wǎng)行業(yè)的快速發(fā)展，敏捷、精益方法論的深入人心，單塊架構(gòu)系統(tǒng)面臨的挑戰(zhàn)，容器虛擬化技術(shù)（Docker），

2.3 微服務(wù)和SOA

2.3.1 SOA（Service-Oriented Architecture，面向服務(wù)架構(gòu)）

2.3.2 微服務(wù)和SOA

2.4 微服務(wù)的本質(zhì)

1） 服務(wù)作為組件（組件能獨(dú)立部署）;2）圍繞業(yè)務(wù)組織團(tuán)隊(duì);3）關(guān)注產(chǎn)品而非項(xiàng)目;4）技術(shù)多樣性（支持各種開發(fā)語言）;5）業(yè)務(wù)數(shù)據(jù)獨(dú)立（數(shù)據(jù)庫(kù)也獨(dú)立）;6）基礎(chǔ)設(shè)置自動(dòng)化;7）演進(jìn)式架構(gòu)

2.5 微服務(wù)不是銀彈

獨(dú)立性，單一職責(zé)，技術(shù)多樣性

2.5.1 分布式系統(tǒng)的復(fù)雜度：性能，可靠性，異步，數(shù)據(jù)一致性，工具

2.5.2 運(yùn)維成本 配置，部署，監(jiān)控與告警，日志收集

2.5.3 部署自動(dòng)化

2.5.4 DevOps 與組織架構(gòu)

2.5.5 服務(wù)間的依賴測(cè)試

2.5.6 服務(wù)間的依賴管理

微服務(wù)架構(gòu)將一個(gè)應(yīng)用拆分成多個(gè)獨(dú)立的、具有業(yè)務(wù)屬性的服務(wù)，每個(gè)服務(wù)運(yùn)行在不同的進(jìn)程中，服務(wù)與服務(wù)之間通過輕量級(jí)的通信機(jī)制互相協(xié)作、互相配合，從而為終端用戶提供業(yè)務(wù)價(jià)值。同時(shí)，每個(gè)服務(wù)可以根據(jù)業(yè)務(wù)邏輯，采用不同的語言、框架、工具以及存儲(chǔ)技術(shù)來解決業(yè)務(wù)問題。因此，微服務(wù)架構(gòu)強(qiáng)調(diào)的是一種獨(dú)立開發(fā)、獨(dú)立測(cè)試、獨(dú)立部署、獨(dú)立運(yùn)行的高度自治的架構(gòu)模式，也是一種更靈活、更開放、更松散的演進(jìn)式架構(gòu)。

3.構(gòu)建第一個(gè)服務(wù)

3.1 場(chǎng)景分析；3.2任務(wù)拆分

1）Hello World API;2）代碼測(cè)試與靜態(tài)檢查；3）構(gòu)建Docker映像；4）部署Docker映像；5）持續(xù)集成與交付；6）監(jiān)控與告警；7）日志聚合；8）功能迭代

4.Hello World API

Ruby；

Rack：Ruby的Web應(yīng)用抽象接口；

Rack Gem： Rack輔助類的集合；

RSpec：代碼測(cè)試工具

Rubocop：代碼的靜態(tài)檢查

5.構(gòu)建Docker映像

Docker：開源的Linux 應(yīng)用容器（Linux Container）引擎。

Boot2docker：Mac下輕松搭建整個(gè)Docker

Docker Hub：

Docker 映像存儲(chǔ)介質(zhì)的比較

6.部署Docker映像

AWS:Amazon Web Services

Amazon EC2： （Amazon Elastic Compute Cloud）

Infrastructure As Code：基礎(chǔ)設(shè)施自動(dòng)化

7.持續(xù)交付流水線

Snap-CI： 持續(xù)集成工具，ThoughtWorks

提交、驗(yàn)證、構(gòu)建、發(fā)布。

Jenkins

8.日志聚合

Splunk：日志管理工具，日志聚合，日志搜索，語義提取，對(duì)結(jié)果進(jìn)行分組、聯(lián)合、拆分和格式化，強(qiáng)大的可視化功能，電子郵件提醒功能。

核心：數(shù)據(jù)（采集器）轉(zhuǎn)發(fā)器、數(shù)據(jù)索引器、搜索、分析和可視化、

LogStash：收集日志、過濾日志、結(jié)果輸出。

ELK： ElasticSearch、LogStash、Kibana

9.監(jiān)控與告警

Zabbix、Ganglia、NewRelic、Nagios、OneAPM。

Nagios： Nagios Ain’t Goona Insist on Saintood，免費(fèi)的開源IT基礎(chǔ)設(shè)施監(jiān)控系統(tǒng)。 能有效監(jiān)控Windows、LInux、VMware和UNIX主機(jī)狀態(tài)以及交換機(jī)、路由器等網(wǎng)絡(luò)設(shè)置。同事，它能夠?qū)崿F(xiàn)錯(cuò)誤通知、事件處理。一旦主機(jī)或服務(wù)狀態(tài)出現(xiàn)異常，Nagios會(huì)發(fā)送郵件或短信第一時(shí)間通知IT運(yùn)維人員，并在狀態(tài)恢復(fù)正常后發(fā)出郵件或短信通知。

Nagios結(jié)構(gòu)： Nagios核心、Nagios插件。

Nagios網(wǎng)站： http://www.nagios.org/

Nagios原理，Nagios安裝，Nagios配置。

10.功能迭代

10.1定義模型；10.2持久化模型;10.3 定義表現(xiàn)形式，10.4實(shí)現(xiàn)API;10.5服務(wù)描述文件

11.微服務(wù)與持續(xù)交付

持續(xù)交付的核心：小、頻、快。小批量?jī)r(jià)值流動(dòng)，頻繁可發(fā)布，快速反饋。

微服務(wù)架構(gòu)與持續(xù)交付：

１） 開發(fā)

獨(dú)立代碼庫(kù)、服務(wù)說明文件、代碼所有權(quán)團(tuán)隊(duì)、有效的代碼版本管理工具【git，Mercurial，svn】、代碼靜態(tài)檢查工具【SonarQube，cane】、易于本地運(yùn)行）；

２） 測(cè)試：

集成測(cè)試的二義性，mock和stub，接口測(cè)試，測(cè)試的有效性

3） 持續(xù)集成： Jenkins，Bamboo，在線持續(xù)集成平臺(tái)：Travis-CI，Snap-CI.

4） 構(gòu)建： Docker

5） 部署： A.部署環(huán)境：基于云平臺(tái)（IAAS，PAAS），基于數(shù)據(jù)中心，基于容器技術(shù)（Docker）

B.部署方式：手動(dòng)部署，腳本部署，基礎(chǔ)設(shè)施部署自動(dòng)化（Chef，Puppet，Ansible），應(yīng)用部署自動(dòng)化，映像部署，容器部署

6）運(yùn)維： 監(jiān)控，告警，日志聚合

Asgard： netflix asgard https://github.com/Netflix/asgard

12. 微服務(wù)與輕量級(jí)通信機(jī)制

12.1 同步通信與異步通信

1）同步通信與一步通信的選擇 ;

2）遠(yuǎn)程調(diào)用RPC（Remote Procedure Call 遠(yuǎn)程過程調(diào)用） 遠(yuǎn)程過程的核心：客服端/服務(wù)端模式（客戶端客戶代理存根［Stub］，服務(wù)器代理存根［Skeleton］）;RMI（Remote Method Invocation 遠(yuǎn)程方法調(diào)用）

優(yōu)點(diǎn)：耦合度高

缺點(diǎn)：靈活性差，依賴于變成語言以及特定平臺(tái)，

二進(jìn)制，客戶/服務(wù)端提供序列化，反序列化操作，任何一方發(fā)生變化，另一方就要造成影響

3）REST（Representational State Transfer 表述性狀態(tài)描述;Resource 資源［返回?cái)?shù)據(jù)］，Representation 表達(dá)，State Transfer狀態(tài)轉(zhuǎn)移，Uniform Interface 統(tǒng)一接口 GET，POST，PUT，DELETE） 概述，軟件架構(gòu)風(fēng)格，

優(yōu)點(diǎn) ：與語言無關(guān)，與平臺(tái)無關(guān)，水平伸縮容易。

缺點(diǎn) ：如何標(biāo)準(zhǔn)化資源結(jié)構(gòu)：業(yè)務(wù)增長(zhǎng)，邏輯增加后，服務(wù)器端對(duì)內(nèi)容的響應(yīng)結(jié)構(gòu)會(huì)越來越復(fù)雜［響應(yīng)結(jié)構(gòu)：是指服務(wù)器段的響應(yīng)內(nèi)容結(jié)構(gòu)，即資源結(jié)構(gòu)］，++可能企業(yè)內(nèi)部的不同部門，不同小組，對(duì)同一資源，所定義的結(jié)構(gòu)不盡相同++.

如何處理資源的相關(guān)鏈接： 大多數(shù)返回JSON，JSON最大的遺憾就是沒有對(duì)超鏈接處理做內(nèi)置的支持。對(duì)于調(diào)用的客戶端，++每次需要查看相關(guān)的接口文檔，才能了解如何修改資源的狀態(tài)++.

如：多個(gè)接口：獲取用戶接口，獲取用戶好友接口，用戶文章接口。如果REST只有開放三個(gè)接口，但是用戶好友和用戶文章實(shí)際上是用戶接口的子鏈接就可以的，但是JSON不支持。

REST的HTTP并不是低延時(shí)通信的最好選擇 對(duì)低延時(shí)要求的場(chǎng)景，可以選擇底層協(xié)議，如果UDP（User Datagram Protocol）或其它的RPC框架。

開發(fā)成本略高 傳輸格式為JSON或XML，則需要來解析文本格式協(xié)議，還好當(dāng)前開源工具庫(kù)成熟。

4）HAL（Hypertext Application Language） ： 輕量級(jí)超文本應(yīng)用描述協(xié)議。HAL的實(shí)現(xiàn)基于REST，并有效的解決了REST中的資源結(jié)構(gòu)標(biāo)準(zhǔn)化和如何有效定義資源鏈接的問題。

核心：狀態(tài)（State），鏈接（Links），子資源（Embedded Resource）。

狀態(tài) 資源本身固有的屬性。

鏈接 定義了與當(dāng)前資源相關(guān)的一組資源的鏈接的集合。包括鏈接名稱、目標(biāo)URI，訪問URI的參數(shù)。

子資源 描述在當(dāng)前資源的內(nèi)容，其嵌套資源的定義。

HAL瀏覽器： （HAL Brower）

5）MQ ：核心部分，訪問方式.RabbitMQ，ActiveMQ，ZeroMQ

核心部分 ： 持久性（內(nèi)存，磁盤，數(shù)據(jù)庫(kù)），排隊(duì)標(biāo)準(zhǔn)（常見FIFO），安全策略，清理策略，處理通知

訪問方式 拉模式，推模式

消息隊(duì)列的優(yōu)缺點(diǎn)： 優(yōu)點(diǎn)： 服務(wù)間耦合，異步通信，消息的持久化以及恢復(fù)支持。

缺點(diǎn)： 實(shí)現(xiàn)復(fù)雜度的增加，平臺(tái)或者協(xié)議依賴，維護(hù)成本高，

6）* 后臺(tái)任務(wù)處理系統(tǒng)* Resque=>Sidekiq（ruby），Delayed_job

輕量級(jí)通信，維護(hù)成本低，SDK和API支持

13.微服務(wù)與測(cè)試

13.1微服務(wù)的結(jié)構(gòu)

業(yè)務(wù)模型（Domain），業(yè)務(wù)邏輯（Service/Business Logic），模型存儲(chǔ)（Respository），資源定義（Resource 包括表述內(nèi)容，表述格式），網(wǎng)關(guān)集成（Gateway/Http Client）。

13.2微服務(wù)的測(cè)試策略

測(cè)試金字塔。 單元測(cè)試，接口（契約）測(cè)試，集成測(cè)試，組件測(cè)試，端到端測(cè)試，探索。

單元測(cè)試 （Unit Testing）被測(cè)單元依賴于模擬部分（MOCK，STUB），被測(cè)單元依賴于真實(shí)部分。

接口（契約）測(cè)試 Pact測(cè)試框架

集成測(cè)試 （Integration Testing），自頂向下集成（Top-Down Integration），自底向上集成（Bottom-Up Integration）。測(cè)試內(nèi)容： 網(wǎng)關(guān)，模型存儲(chǔ)。

集成測(cè)試弊端： 運(yùn)行效率低，運(yùn)行結(jié)果不穩(wěn)定，反饋周期慢。

組件測(cè)試 （Component Testing），進(jìn)程內(nèi)測(cè)試，進(jìn)程外測(cè)試。

端到端測(cè)試 （End-To-End Testing，System Testing）

14.使用微服務(wù)架構(gòu)改造遺留系統(tǒng)

14.1 改造策略

最小修改（優(yōu)先修改緊急，核心功能），功能剝離（構(gòu)建接口，分離核心功能），數(shù)據(jù)解耦（數(shù)據(jù)庫(kù)獨(dú)立），數(shù)據(jù)同步（ETL Extract，Transform，Load），迭代替換（最小修改-》功能剝離-》數(shù)據(jù)解耦-》數(shù)據(jù)同步（-》獨(dú)立服務(wù)）-》功能剝離）。

14.2快速開發(fā)實(shí)踐

微服務(wù)快速開發(fā)模板（Microservice Template）：快速開發(fā)模板（Webmachine或Grape 作為Web框架，RESTful和JSON構(gòu)建服務(wù)之間的通信方式，RSpec作為測(cè)試框架），代碼生成工具，持續(xù)集成模板（Bamboo），一鍵部署工具（Asgard）。