微服務架構與實踐摘要

一、微服務架構圖：

二、技術介紹：

三、為什么選擇微服務架構

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

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

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

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

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

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

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

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

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

微服務架構實施

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

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

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

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

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

我們這里簡單總結下實施的要點：

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

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

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

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

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

服務流控：降級、限流

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

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

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

服務配置：中心化配置服務支持

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

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

自進化的微服務架構

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

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

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

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

微服務架構與架構師

架構師的一個角色是技術決策者，技術決策涉及很多權衡取舍（trade-off），而微服務架構給了架構師更多權衡取舍的空間。

每個微服務實現層面的技術決策更多由服務負責人決定，服務的分拆伴隨著決策權和責任的分拆，這也減輕了整體應用負責人的責任負擔。

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

分拆了服務實現的技術決策權，那何時又該適當的介入以避免服務實現不當危及整體系統(tǒng)的安全？

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

架構師工作在抽象和具體兩個層面：

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

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

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

1.1 三層架構

三層架構包括表示層、業(yè)務邏輯層、數據訪問層。

1.2 單塊架構

所有的功能在一個工程項目中。

單塊架構常見的架

1.3 互聯網產品特性

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

2.微服務架構綜述

2.1 什么是微服務

微服務架構模型（Microservice Architect Pattern）

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

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

2.1.1 多微才夠微

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

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

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

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

業(yè)務： 訂單，產品，合同

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

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

2.1.2 單一職責

高內聚：一個模塊各個元素彼此結合的緊密度高。

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

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

### 2.1.2 輕量級通信

服務之間應通過輕量級的通信機制，實現彼此間的互通互聯，互相協作。

格式： XML，JSON

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

2.1.3 獨立性

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

2.1.4 進程隔離

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

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

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

2.2 微服務的誕生背景

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

2.3 微服務和SOA

2.3.1 SOA（Service-Oriented Architecture，面向服務架構）

2.3.2 微服務和SOA

2.4 微服務的本質

1） 服務作為組件（組件能獨立部署）;2）圍繞業(yè)務組織團隊;3）關注產品而非項目;4）技術多樣性（支持各種開發(fā)語言）;5）業(yè)務數據獨立（數據庫也獨立）;6）基礎設置自動化;7）演進式架構

2.5 微服務不是銀彈

獨立性，單一職責，技術多樣性

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

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

2.5.3 部署自動化

2.5.4 DevOps 與組織架構

2.5.5 服務間的依賴測試

2.5.6 服務間的依賴管理

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

3.構建第一個服務

3.1 場景分析；3.2任務拆分

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

4.Hello World API

Ruby；

Rack：Ruby的Web應用抽象接口；

Rack Gem： Rack輔助類的集合；

RSpec：代碼測試工具

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

5.構建Docker映像

Docker：開源的Linux 應用容器（Linux Container）引擎。

Boot2docker：Mac下輕松搭建整個Docker

Docker Hub：

Docker 映像存儲介質的比較

6.部署Docker映像

AWS:Amazon Web Services

Amazon EC2： （Amazon Elastic Compute Cloud）

Infrastructure As Code：基礎設施自動化

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

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

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

Jenkins

8.日志聚合

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

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

LogStash：收集日志、過濾日志、結果輸出。

ELK： ElasticSearch、LogStash、Kibana

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

Zabbix、Ganglia、NewRelic、Nagios、OneAPM。

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

Nagios結構： Nagios核心、Nagios插件。

Nagios網站： http://www.nagios.org/

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

10.功能迭代

10.1定義模型；10.2持久化模型;10.3 定義表現形式，10.4實現API;10.5服務描述文件

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

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

微服務架構與持續(xù)交付：

１） 開發(fā)

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

２） 測試：

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

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

4） 構建： Docker

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

B.部署方式：手動部署，腳本部署，基礎設施部署自動化（Chef，Puppet，Ansible），應用部署自動化，映像部署，容器部署

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

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

12. 微服務與輕量級通信機制

12.1 同步通信與異步通信

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

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

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

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

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

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

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

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

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

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

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

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

4）HAL（Hypertext Application Language） ： 輕量級超文本應用描述協議。HAL的實現基于REST，并有效的解決了REST中的資源結構標準化和如何有效定義資源鏈接的問題。

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

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

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

子資源 描述在當前資源的內容，其嵌套資源的定義。

HAL瀏覽器： （HAL Brower）

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

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

訪問方式 拉模式，推模式

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

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

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

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

13.微服務與測試

13.1微服務的結構

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

13.2微服務的測試策略

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

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

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

集成測試 （Integration Testing），自頂向下集成（Top-Down Integration），自底向上集成（Bottom-Up Integration）。測試內容： 網關，模型存儲。

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

組件測試 （Component Testing），進程內測試，進程外測試。

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

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

14.1 改造策略

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

14.2快速開發(fā)實踐

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