微服務的出現，標誌了又乙個新的里程碑，似乎你不知道微服務就代表你好像out了一樣。微服務是業務服務化，將soa更好的延續了下去。配合restful也能夠更好的提供api介面。
簡單來說就是微服務把各種各樣的小的服務區分開來當做乙個當度的應用跑在伺服器上，並且他的通訊機制也是十分簡單的，使用rest或者rpc都行。他們可以各自對自己的業務進行處理。各個服務直接可以用不同的語言開發，這樣提高了不同技術團隊之間的職能。
微服務的特點：
1、微服務的元件是以服務的形式存在的。
2、由各個不同的業務來切分整個大服務。
3、微服務是產品，不是專案。微服務在整個開發生命週期十分長久，並且需要後期團隊的維護，就是因為微服務的特性，才使得維護更加的方便。
4、簡單的通訊機制，不論是rpc還是restful，都簡化了系統服務之間的訪問，並不像曾經的wsdl那麼複雜。
5、分散治理，這個就是跟傳統巨石應用區別開來了。不同的服務都是乙個很小的元件，那麼在組裝的時候不同的服務可以組裝成不同的微服務，十分靈活。
6、資料庫分散管理，在做巨石應用的時候，乙個專案就是訪問乙個資料庫。那麼微服務不是，每個不同的業務訪問並且管理的都是自己的資料庫，與各個不同的服務之間的資料庫是不同的，這樣也做到了資料的隔離。
7、容錯性，每個服務宕掉不可訪問的時候，微服務可以為每個服務進行監控與恢復。
其實我們平時接觸的最多的還是soa，soa是偏向系統的解決方案，而微服務面向服務，微服務的顆粒度要小很多，soa比較大，哪怕是乙個小更新其實也是要重啟對應的系統，而微服務卻不是。考慮一下玩王者榮耀的時候，可以不停機更新，是不是乙個道理？
soa的缺點：
隨著時間的推移，**庫會越來越大，如果團隊來了乙個新人是十分恐懼的。
開發工具也會隨著**量的增多變得緩慢，這樣導致的就算是開發效率的降低。
伺服器啟動變慢，**變多，容器在載入的時候讀取的**檔案也越多，這樣導致容器每次啟動都會比較慢。
持續部署相對複雜，不利於運維更新。每次更新整個系統必須關閉，使用者無法訪問。
可擴充套件性降低。
微服務的特點：
各服務之間通過json或者xml的資料形式通訊。把一組類似的功能或者業務作為乙個單獨的微服務來做。比如訂單服務讓訂單核心團隊來維護。cms由cms團隊來維護。
服務之間通過rest或者rpc來通訊，甚至使用訊息佇列。
服務獨立開發和部署，相互不影響，技術只能部門也相互不影響。
服務之間相互解耦，每個服務都有自己對應的資料庫。注意，這需要做好資料一致性，比如tcc。
每個服務獨立部署，對於頻繁更新版本的專案由很好的效率。
便於擴充套件團隊和組織架構。
整個微服務相對技術難度比soa加大，需要開發人員對技術有一定的持續投入。
分布式事務比單體應用難處理。
生產環境部署複雜度提公升，需要運維人員有一定的功底。
微服務的難點：
很多初創型公司對於開發進度是十分有要求的，起初並不會使用微服務架構，而是單體應用或者soa，為的是更好更快速的發展自身的業務。然而發展到一定規模後，整個技術架構發生變化，要重構為微服務，這個時候的技術選型以及如何重構，和整個團隊技術人員的參與就相對來說是個難點了。
分布式 集群 微服務
微服務是架構設計方式 分布式是系統部署工作方式 集群是個物理形態 微服務是啥？這裡不引用書本上的複雜概論了，簡單來說微服務就是很小的服務，小到乙個服務只對應乙個單一的功能，只做一件事。這個服務可以單獨部署執行，服務之間可以通過rpc來相互互動，每個微服務都是由獨立的小團隊開發，測試，部署，上線，負責...
微服務 分布式服務框架
spring cloud rest與rpc比較 dubbo 和 spring cloud 對比 通訊協議 傳輸的格式都屬於協議 服務路由 分布式服務上線時都是集群組網部署，集群中會存在某個服務的多例項，消費者如何從服務列表中選擇合適的服務提供者進行呼叫，這就涉及到服務路由。分布式服務框架需要能夠滿足...
分布式系統的那些事兒（五） 容錯與故障
我們都經歷過巨石應用，單一應用某個功能誘發的故障導致整個站點掛掉，任何人都無法訪問，只能一一排錯再部署上線，這樣造成的影響就是使用者的流失。而分布式應用就沒有這樣的問題，就算某個節點出現故障，那麼主備切換，替換主節點，整個系統還是照樣執行，完全沒有訪問不了的現象。要使系統達到一定的容錯性，那麼 首先...