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

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

二、技術(shù)介紹：

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

首先，當然是該套架構(gòu)方法有著名的成功經(jīng)驗才導致大家去了解與學習它。

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

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

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

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

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

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

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

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

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

把 1 個應(yīng)用進程部署到 1 臺主機，部署復雜度是 1 x 1 = 1，我們有 200 臺主機，那么部署復雜度是 1 x 200 = 200。

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

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

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

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

我們這里簡單總結(jié)下實施的要點：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

文章開頭說了，這是我們實施系統(tǒng)的第四個大版本，而之前每一個大版本升級都是一次舊城倒新城的整體搬遷。而微服務(wù)架構(gòu)天然的自然進化屬性是否預示著這應(yīng)該是最后一個大版本升級了？微服務(wù)架構(gòu)述說著沒有永恒的架構(gòu)，只有進化的架構(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ò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）

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

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

2.1.1 多微才夠微

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

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

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

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

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

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

團隊自主性： 考慮團隊的溝通及寫作成本，一般建議不超過十人。

2.1.2 單一職責

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

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

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

### 2.1.2 輕量級通信

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

格式： XML，JSON

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

2.1.3 獨立性

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

2.1.4 進程隔離

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

因為增加了部署和擴展的復雜度，建議還是一個服務(wù)一個節(jié)點。

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

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

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

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

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

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

2.5.3 部署自動化

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

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

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

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

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

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

1）Hello World API;2）代碼測試與靜態(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：代碼測試工具

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

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

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

Boot2docker：Mac下輕松搭建整個Docker

Docker Hub：

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

6.部署Docker映像

AWS:Amazon Web Services

Amazon EC2： （Amazon Elastic Compute Cloud）

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

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

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

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

Jenkins

8.日志聚合

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

核心：數(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，免費的開源IT基礎(chǔ)設(shè)施監(jiān)控系統(tǒng)。 能有效監(jiān)控Windows、LInux、VMware和UNIX主機狀態(tài)以及交換機、路由器等網(wǎng)絡(luò)設(shè)置。同事，它能夠?qū)崿F(xiàn)錯誤通知、事件處理。一旦主機或服務(wù)狀態(tài)出現(xiàn)異常，Nagios會發(fā)送郵件或短信第一時間通知IT運維人員，并在狀態(tài)恢復正常后發(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實現(xiàn)API;10.5服務(wù)描述文件

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

持續(xù)交付的核心：小、頻、快。小批量價值流動，頻繁可發(fā)布，快速反饋。

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

１） 開發(fā)

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

２） 測試：

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

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

4） 構(gòu)建： Docker

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

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

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

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

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

12.1 同步通信與異步通信

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

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

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

缺點：靈活性差，依賴于變成語言以及特定平臺，

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

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

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

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

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

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

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

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

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

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

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

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

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

HAL瀏覽器： （HAL Brower）

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

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

訪問方式 拉模式，推模式

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

缺點： 實現(xiàn)復雜度的增加，平臺或者協(xié)議依賴，維護成本高，

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

輕量級通信，維護成本低，SDK和API支持

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

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

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

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

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

單元測試 （Unit Testing）被測單元依賴于模擬部分（MOCK，STUB），被測單元依賴于真實部分。

接口（契約）測試 Pact測試框架

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

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

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

端到端測試 （End-To-End Testing，System Testing）

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

14.1 改造策略

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

14.2快速開發(fā)實踐

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