相比於單機服務與其他架構，微服務架構的主要特徵是元件化、松耦合、獨立、去中心化。主要表現在如下幾個方面：
細粒度的服務分解；將專案中每個模組/每個職責拆分出來，專注做好一件事情。
獨立部署執行和擴充套件；每個微服務又是乙個單獨的專案，獨立執行在自己的程序裡。它可以不依賴於其他服務進行單獨使用和靈活擴充套件。這種執行和部署方式能夠賦予系統靈活的**組織和發布節奏，使得快速互動和應對變化成為可能。
服務間輕量通訊；各個服務之間相互獨立又通過協議進行通訊，協作完成更複雜的業務。
去中心化，獨立開發與自治；技術選型靈活，服務之間可以用不同的技術甚至不同的語言。
三、微服務為我們解決了哪些問題
相對於傳統單機服務，微服務不僅解決了之前存在的問題，還擁有一些單機服務所不具備的優點：
便於開發，降低複雜度；各個團隊中分別維護各自服務，不會出現等待的無用功的間隙
並且更新迭代的時候，不必再學習整個專案的業務**，僅關注所在的服務模組即可
業務解耦；各個服務間通過協議互相通訊，**沒有強耦合性，互不干擾
獨立部署；每個模組都可以單獨部署，所以在上線新功能的時候只需發布相應的模組即可，既降低測試的工作量也降低了服務發布的風險（單服務情況下，新增需求可能就得把整個的流程測試再回歸一下，並且上線失敗的話整個專案都要回滾，而微服務則只需要回滾相應的模組即可）
穩定性強；單個服務出現問題，其他服務仍可繼續工作，這在技術潮流中是非常重要的乙個進步，結合集群部署，我們完美的實現不停機更新
例如訂單服務故障，使用者仍然通過商品服務可以瀏覽商品資訊，檢視評價等
擴充套件性強；可以根據不同服務的流量和壓力，進行自主擴充套件
即商品服務流量高，而訂單服務流量低，則可以部署兩個商品服務，乙個訂單服務，更加靈活
四、當前微服務面臨的挑戰
在當前的場景中，微服務也不是萬能的一種方案。至少在現階段，它還存在著如下幾個問題：
運維成本增加；需要部署n個專案，對於單機服務來講，只需要維護乙個專案就行了。但是對於微服務來講，由於專案是多個微服務構成的，每個模組都需要進行維護
問題追蹤難度增加；需要分析整個請求的呼叫鏈，逐步檢視各個服務的狀況，依此來定位和解決問題
內容重複；對部分業務，流程大致相同時，如果不能很方便的將**封裝，就可能導致在多個服務中有些重複性的**
除此外還有日誌重複，乙個呼叫鏈可能要呼叫n個服務，在追蹤問題時，每個服務都要對引數和響應進行記錄。這樣就導致同樣乙份內容在多個地方重複出現
增加開支成本 , 標準的的微服務部署方案，應該是每乙個服務部署到乙個伺服器上，各個伺服器之間互不干擾，但這樣的話無疑就需要更高的伺服器成本
當前的主流方案是利用docker採用單伺服器多映象隔離，但docker映象並沒有傳統虛擬機器的高度資源隔離水平，它仍然需要很多共享的東西。這就導致了如果其中乙個docker核心崩潰或占用共享資源，其他容器也會受到影響
四、當前微服務面臨的挑戰
在當前的場景中，微服務也不是萬能的一種方案。至少在現階段，它還存在著如下幾個問題：
運維成本增加；需要部署n個專案，對於單機服務來講，只需要維護乙個專案就行了。但是對於微服務來講，由於專案是多個微服務構成的，每個模組都需要進行維護
問題追蹤難度增加；需要分析整個請求的呼叫鏈，逐步檢視各個服務的狀況，依此來定位和解決問題
內容重複；對部分業務，流程大致相同時，如果不能很方便的將**封裝，就可能導致在多個服務中有些重複性的**
除此外還有日誌重複，乙個呼叫鏈可能要呼叫n個服務，在追蹤問題時，每個服務都要對引數和響應進行記錄。這樣就導致同樣乙份內容在多個地方重複出現
增加開支成本 , 標準的的微服務部署方案，應該是每乙個服務部署到乙個伺服器上，各個伺服器之間互不干擾，但這樣的話無疑就需要更高的伺服器成本
當前的主流方案是利用docker採用單伺服器多映象隔離，但docker映象並沒有傳統虛擬機器的高度資源隔離水平，它仍然需要很多共享的東西。這就導致了如果其中乙個docker核心崩潰或占用共享資源，其他容器也會受到影響
1 akf拆分原則
x軸 水平擴充套件 增加機器 負載均衡
y軸 功能、業務 拆分
z軸 資料分割槽 如按地域劃分
2 前後端分離原則 分工精細
前端服務
後端服務
3 無狀態服務
不算子據的部分 稱為無狀態的服務 前端
運算元據的部分 稱為有狀態的服務 後端
優點：容易擴充套件
4 restful 通訊風格
無狀態的通訊協議 http
微服務架構的設計原則
高內聚 低耦合。無縫的 api 整合。為每一項服務分配唯一的資源標識。實時流量管理。最小化資料表，以優化載入。通過內 外部 api，執行持續監控。為每個微服務隔離資料的儲存。這對於限制資料的訪問和避免 服務的耦合 是非常有用的。例如 基於使用者的分類資料，我們可以實施命令查詢的責任分離 comman...
微服務劃分原則
確切地說，服務中 的劃分原則更多的是架構設計經驗總結，我們很難對 些具體的問題給 個精確的量化指標，但有 點，我很反對現在微服務中的loc line of code 這種指標，即 的 數來衡量 個微服務落地的標準。架構本來就是 個追求平衡的藝術，不僅是設計原則上的平衡，還要在技術 成本 資源 效能 ...
20190115 微服務拆分原則
微服務拆分 1 對於第乙個問題，是乙個無法度量的問題，粒度多細才是細，多粗才算粗，根本就是你說了算，而且，很多時候，並非夠細或夠粗就是好事情。對於粒度的劃分，李運華老師提出了以專案組開發人員的數量來劃分粒度的想法，我覺得很認同。乙個服務，應該以2 3個人 可以根據團隊成員構成進行分組，以組概念來權衡...