微服務基礎概念認知總結

因爲從未使用過Spring Cloud、Dubbo等微服務框架，因此只能不斷地從微服務基礎知識出發，不讓本身侷限於某一種工具框架上。如下知識摘自一些本身看過的微服務相關的書上，還有一些本身對微服務的理解。

單體應用存在的問題

複雜性高

單體應用項目包含的模塊很是多、模塊的邊界模糊、依賴關係不清楚、代碼質量層次不齊、混亂地堆砌在一塊兒。每次修復BUG或者新增功能，涉及的部分比較多，存在着隱含的缺陷，有可能一小部分的改變會影響到其餘功能。

技術債務

雖然時間的推移、需求變動和人員的更迭，會逐漸造成應用程序的技術債務，而且越積越多。

部署頻率低

隨着代碼的增多，構建和部署的時間也會增長。而在單體應用中，每次功能的變動或缺陷的修復都會致使須要從新部署整個應用，而且上線前伴隨着測試人員對整個系統功能的迴歸測試。全量部署的方式耗時長、影響範圍大、風險高，這使得單體應用項目上線部署的頻率較低。

可靠性差

一小處功能模塊出問題，會致使整個應用的崩潰。

擴展能力受限

單體應用中只能做爲一個總體進行擴展，沒法根據業務模塊的須要進行伸縮。

阻礙技術創新

單體應用每每使用統一的技術平臺或方案解決全部的問題，團隊中的每一個成員都必須使用相同的開發語言和框架，要想引入新框架或新技術平臺會很是困難。

微服務

微服務一詞，最初來源於Martin Fowler，對微服務也沒有一個明確的定義，可是卻有必定的描述。

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automasted deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

意思是微服務架構風格是一種將單一應用程序開發成一組小型服務的方法，每一個服務運行在本身的進程中，服務間通訊採用輕量級通訊機制（一般用HTTP資源API）。這些服務圍繞業務能力構建而且可經過自動部署機制獨立部署。這些服務共用一個最小型的集中式的管理，服務可用不一樣的語言開發，使用不一樣的數據存儲技術。

Martin Fowler

Martin Fowler是國際著名的面向對象分析設計、UML、模式等方面的專家，敏捷開發方法的創始人之一，現爲ThoughtWorks公司的首席科學家。

他改變了人類開發軟件的模式，他被開發者們尊爲「教父」，他從不與媒體談論技術之外的事情。

微服務架構應該具有的特性

• 每一個微服務可獨立運行在本身的進程裏。
• 一系列獨立運行的微服務共同構建起整個系統。
• 每一個服務爲獨立的業務開發，一個微服務只關注某個特定的功能，例如訂單管理、用戶管理等。
• 微服務之間經過一些輕量的通訊機制進行通訊，例如經過RESTful API進行調用。
• 可使用不一樣的語言與數據存儲技術。
• 全自動的部署機制。

微服務架構的優勢

易於開發和維護

一個微服務只會關注一個特定的業務功能，因此它業務清晰、代碼量較少。開發和維護單個微服務相對簡單。而整個應用是由若干個微服務構建而成的，因此整個應用也會被維持在一個可控狀態。

單個微服務啓動較快

單個微服務代碼量較少，因此啓動會比較快。

局部修改容易部署

單體應用只要有修改，就得從新部署整個應用，微服務解決了這樣的問題。通常來講，對某個微服務進行修改，只須要從新部署這個服務便可。

技術棧不受限

在微服務架構中，能夠結合項目業務及團隊特色，合理地選擇技術棧。例若有些服務科使用MySQL，有些則使用MongoDB；有些使用Java，有些使用Python。任何語言都不是萬能的，能夠根據不一樣的業務場景選擇更適用的開發語言或框架。

按需伸縮

可根據需求，實現細粒度的擴展。例如，系統中的某個微服務遇到了瓶頸，能夠結合這個微服務的業務特色，增長內存、升級CPU或者是增長節點。

微服務架構的應用雖然存在這些優勢，可是在實現的過程當中也存在更多單一應用所沒有的挑戰。

微服務架構面臨的挑戰

運維要求較高

更多的服務意味着更多的運維投入。在單體架構中，只須要保證一個應用的正常運行。而在微服務中，須要保證幾十甚至幾百個服務的正常運行與協做，這給運維帶來了很大的挑戰。

分佈式固有的複雜性

使用微服務構建的是分佈式系統。對於一個分佈式系統，系統容錯、網絡延遲、分佈式事務等都會帶來巨大的挑戰。

接口調整成本高

微服務之間經過接口進行通訊。若是修改某一個微服務的API，可能全部使用了該接口的微服務都須要作調整。

重複勞動

不少服務可能都會使用到相同的功能，而這個功能並無達到分解爲一個微服務的程度，這個時候，可能各個服務都會開發這一功能，從而致使代碼重複。儘管可使用共享庫來解決這個問題，可是共享庫在多語言環境下就不必定行得通了。

微服務設計原則

單一職責原則

單一職責原則是指一個單元(類、方法或者服務等)只應關注整個系統功能中單獨、有界限的一部分。單一職責原則能夠幫助咱們更優雅的開發、更敏捷的交付。

服務自治原則

服務自治是指每一個微服務應該具有獨立的業務能力、依賴與運行環境。在微服務架構中，服務是獨立的業務單元，應該與其餘服務高度解耦。每一個微服務從開發、測試、構建、部署，都應當能夠獨立運行，而不該該依賴其餘的服務。

輕量級通訊機制

微服務之間應該經過輕量級的通訊機制進行交互。輕量級的通訊機制應該具有兩點：

1. 體量較輕。
2. 跨語言、跨平臺。

像REST協議就是一種輕量級通信機制，而Java的RMI通信協議則不屬於輕量級通信協議，由於RMI綁定了Java語言。

微服務架構中，經常使用的協議有REST、AMQP、STOMP、MQTT等。

微服務粒度

微服務的粒度是難點，也嚐嚐是爭論的焦點。應當使用合理的粒度劃分微服務，而不是一味的把服務作小。代碼量的多少不能做爲微服務劃分的依據，由於不一樣的微服務在自己的業務複雜性不一樣，代碼量也不一樣。在微服務的設計階段，就應肯定其邊界。微服務之間應相對獨立並保持鬆耦合。

擴展

領域驅動設計（DDD：Domain-Driver Design）

架構是高層的設計，若是設計和理解有誤，必將在實現時帶來各類問題。架構又是最穩定的，不會由於各類具體技術的依賴，好比各類UI框架、ORM框架、IoC框架的更新換代而受到影響。

而在微服務的設計中，重中之重的設計就是須要肯定服務邊界，這個時候就能夠須要提到DDD（領域驅動設計）。

DDD整體結構分爲四層：Infrastructure(基礎實施層)，Domain(領域層)，Application(應用層)，Interfaces(表示層，也叫用戶界面層或是接口層)。

根據DDD做者Eric Evans的說法，須要成功實施DDD主要有兩個條件：

1. 迭代開發過程
2. 訪問領域專家

迭代開發是DDD的生命力量。它能夠實現實驗，探索和調用問題域的主動重構，由於您能夠繼續與領域專家一塊兒得到更多的洞察力。

雲原生架構的方法論與最佳實踐——十二要素應用宣言

• 基準代碼：一份基準代碼，多份部署
• 依賴：顯式聲明依賴關係
• 配置：在環境中存儲配置
• 後端服務：把後端服務當作附加資源
• 構建、發佈、運行：嚴格分離構建和運行
• 進程：以一個或多個無狀態進程運行應用
• 端口綁定：經過端口綁定提供服務
• 併發：經過進程模型進行擴展
• 易處理：快速啓動和優雅終止可最大化健壯性
• 開發環境與線上環境等價：儘量的保持開發、預發佈、線上環境相同
• 日誌：把日誌當作事件流
• 管理進程：後臺管理任務看成一次性進程運行

測試驅動開發（Test-Driven Development，TDD）

測試驅動開發，英文全稱Test-Driven Development，簡稱TDD，是一種不一樣於傳統軟件開發流程的新型的開發方法。它要求在編寫某個功能的代碼以前先編寫測試代碼，而後只編寫使測試經過的功能代碼，經過測試來推進整個開發的進行。這有助於編寫簡潔可用和高質量的代碼，並加速開發過程。 — 摘自百度百科

測試驅動開發的基本過程以下：

1. 快速新增一個測試
2. 運行全部測試（有時候只須要運行一個或一部分），發現新增的測試不能經過
3. 作一些小小的改動，儘快讓測試程序可運行，爲此能夠在程序中使用一些不合情理的方法
4. 運行全部的測試，而且所有經過
5. 重構代碼，以消除重複設計，優化設計結構