微服務是一種架構風格，乙個大型的複雜軟體由乙個或多個微服務組成。系統中每個微服務都可以被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注於完成一件任務並很好地完成任務。在所有情況下，每個任務代表這乙個小的業務能力。
微服務的核心思想是：乙個完整的應用由多個小的、相互獨立的微服務組成，這些微服務執行在自己的程序中，開發和發布都沒有依賴。不同微服務通過一些輕量級互動機制來通訊，例如rpc、http等，服務可獨立拓展伸縮，每個服務定義了明確的邊界，不同的服務甚至可以採用不同的程式語言來實現，由獨立團隊維護。簡單的來說，乙個系統的不同模組轉變成不同的服務！而且服務可以使用不同的技術加以實現！
微服務的目的是為了根據業務有效拆分應用，實現敏捷開發和部署。
2.1 與整體式（單體）應用的區別
微服務與整體式應用的主要差異在於組裝應用元件，微服務架構將相關聯的業務邏輯及資料放在一起形成獨立的邊界，其目的是在不影響其他應用元件（微服務）的情況下更快地交付並推出市場。
整體式應用
微服務應用
程序數將所有功能放到同乙個程序中
拓展方式
通過複製整個應用到多台伺服器實現拓展
快速響應變更
隨著雲化以及應用功能變得越來越頻繁，整體式應用在快速響應市場上顯得越來越力不從心。部分更新，都需要重新部署整個應用
團隊結構
團隊結構呈現垂直化，每個團隊專門負責專門的一塊，比如分為：ui設計團隊、中介軟體團隊、業務開發團隊、資料庫管理團隊等。
可用性乙個服務的不穩定可能導致整個應用出現問題
創新性很難引入新的技術和框架，所有功能都使用的同一種框架
2.2 與soa的區別
看了很多網上對微服務和soa區別的看法，分為兩種，一種是對區別侃侃而談，列舉了很多，另一種認為微服務其實是soa的一種架構實現。從中可以看出微服務和soa還是有很多相似之處的，只是針對業務需求進行區別設計。
如果非要說區別的話，微服務架構與soa最主要的區別在於：微服務不再強調傳統soa架構裡面比較重的esb企業服務匯流排，同時soa的思想進入到單個業務系統內部實現真正的元件化。
1. 通過服務實現應用的元件化
微服務架構中將元件定義為可被獨立代替和公升級的軟體單元，在應用架構設計中通過正整體應用切分成可獨立部署公升級的微服務方式進行元件化設計。
2.圍繞業務能力組織服務
以業務能力為出發點組織服務，微服務團隊的組織結構必須是跨功能的（比如：即管應用也管資料庫），通常團隊功能不會太大。
3. 產品而非專案模式
傳統的應用模式是乙個團隊以專案模式開發完整的應用，開發完成後就交付給運維團隊負責維護，微服務架構則倡導乙個團隊應該負責乙個「微服務」完整的生命週期，「誰開發，誰負責」。
4. 智慧型端點和管道扁平化
微服務架構主張將元件通訊的相關業務邏輯/智慧型放在元件端點側而非放在通訊元件中，通訊機制或元件應該盡量簡單及松耦合。
5. 「去中心化」治理
整體式應用往往傾向於採取單一技術平台，微服務架構則鼓勵使用合適的工具完成各自的任務，每個微服務可以考慮選用最佳工具完成，如不同的程式語言。
6. 「去中心化」資料管理
微服務架構倡導採用多樣性持久化的方法，讓每個微服務管理其自由資料庫，並允許不同微服務採用不同的資料持久化技術。
7. 基礎設施自動化
雲化及自動化部署等技術極大地降低了微服務構建、部署和運維的難度，通過應用持續整合和持續交付等方法有助於達到加速推出市場的目的。
8. 故障處理設計
微服務架構所帶來的乙個後果就是必須考慮每個服務的失敗容錯機制。因此，微服務非常重視建立架構及相關業務指標的實時監控和日誌機制。
9. 演進式的設計
微服務應用更注重快速更新，因此系統會隨時間不斷演進。微服務的設計受業務功能的生命週期等因素影響。如某應用是整體式應用，但逐漸朝微服務應用架構演進，整體式應用仍是核心，但新功能將使用所提供的api構建。再如在某微服務應用中，可代替模組設計的基本原則，在實施後發現某兩個微服務經常必須同時更新，則這可能意味著應將其合併為乙個服務。
優點：每個服務都比較簡單，可以提供更高的靈活性； 微服務架構的方式是松耦合的，可以提供更高的靈活性； 微服務可通過最佳及合適的不同開發語言與工具（比如不同的資料庫）進行開發，能夠做到有的放矢地解決針對性問題； 每個微服務可由不同團隊獨立開發，互不影響，加快推出市場的速度； 微服務架構是持續交付的巨大動力，允許在頻繁發布不同服務的同時保持系統其它部分的可用性和穩定性。
缺點：微服務的想法在實踐上是好的，單當整體實現時也會呈現出複雜性。
運維開銷及成本增加：整體應用可能只需要部署至一小片應用服務區集群，而微服務可能變成需要構建/測試/部署/執行數十個獨立的服務，並可能需要支援多種語言和環境。這導致乙個整體式系統如果由20個微服務組成，可能需要40-60個程序。 必須具有devops開發運維一體化技能：開發人員需要熟知運維與投產環境，開發人員也需要掌握必要的資料儲存技術如nosql，具有較強devops技能的人員比較稀缺。 隱式介面與介面匹配問題：把系統分為多個協作元件後會產生新的介面，這意味著簡單的交叉變化可能需要改變許多元件，並需要協調一起發布。在實際環境中，乙個新品發布可能被迫同時發布大量服務，由於整合點的大量增加，微服務架構會有更高的發布風險。 **重複：某些底層功能需要被多個服務所用，為了避免將」同步耦合引入到系統中「，有時候需要向不同服務新增同樣的**，這就會導致**重複。 分布式系統的複雜性：作為一種分布式系統，微服務引入了複雜性和其他若干問題，例如網路延遲、容錯性、訊息序列化、不可靠的網路、非同步機制、版本化、差異化的工作負載等，開發人員需要考慮以上的分布式系統問題。 非同步機制：微服務往往使用非同步程式設計、訊息並行機制，如果應用存在跨微服務的事務性處理，其實現機制會變得複雜化。 可測性的挑戰：在動態環境下服務間的互動會產生非常微妙的行為，難以視覺化及全面測試。經典微服務往往不太重視測試，更多的是通過監控發現生產環境的異常，進而快速回滾或採取必要的其他行動，但對於特別在意風險規避監管或投產環境錯誤會產生顯著影響的場景下需要特別注意。 部署複雜：乙個單體應用只需要在複雜均衡器後面部署各自的伺服器就好了。每個應用例項是需要配置諸如資料庫和訊息中介軟體等基礎服務。相比之下，乙個微服務應用一般由大批服務構成，這就形成大量需要配置、部署、擴充套件和監控的部分。除此之外，你還需要完成乙個服務發現機制，以用來發現與它通訊服務的位址（包括伺服器位址和埠）。在合適的專案，合適的團隊，採用微服務架構收益會大於成本。 微服務架構有很多吸引人的地方，但在擁抱微服務之前，也需要認清它所帶來的挑戰。 需要避免為了「微服務」而「微服務」。 微服務架構引入策略 – 對傳統企業而言，開始時可以考慮引入部分合適的微服務架構原則對已有系統進行改造或新建微服務應用，逐步探索及積累微服務架構經驗，而非全盤實施微服務架構。
JMS Java訊息服務 入門教程
訊息傳送者和接收者並沒有時間依賴性 當訊息傳送者傳送訊息的時候，無論接收者程式在不在執行，都能獲取到訊息 當接收者收到訊息的時候，會傳送確認收到通知 acknowledgement 發布者和訂閱者有時間依賴性，只有當客戶端建立訂閱後才能接受訊息，且訂閱者需一直保持活動狀態以接收訊息。為了緩和這樣嚴格...
ABP入門教程2 體系架構
點這裡進入abp入門教程目錄 應用程式 庫的分層是一種廣泛接受的技術，可幫助降低複雜性並提高 可重用性。為了實現分層體系結構，asp.net boilerplate遵循 域驅動設計的原理 領域驅動設計 ddd domain driven design 有四個基本層 除了ddd外，現代架構應用程式中還...
微服務與微服務架構
微服務 微服務強調的是服務的大小，它關注的是某乙個點，是具體解決某乙個問題 提供落地對應服務的乙個服務應用,狹意的看,可以看作eclipse裡面的乙個個微服務工程 或者module。例如 訂單服務 支付服務 微服務架構 馬丁.福勒 martin fowler 微服務架構介紹 微服務架構是 種架構模式...