假設乙個場景：網上電影購票系統，涉及的模組有電影模組、訂單模組、使用者模組。
在沒有微服務之前，我們的做法可能是，乙個專案，存放所有的模組資訊，當前，這種做法也沒有問題，可以實現功能，隨著我們的業務系統越來越大，**量，還有使用者人群越來越大，這樣膿腫的專案，就會存在各種各樣的問題，**維護成本，硬體成本，不好維護等等。這樣微服務就應運而生。
我們常說微服務，那什麼是微服務？
所謂的微服務是soa架構下的最終產物，該架構的設計目標是為了肢解業務，使得服務能夠獨立執行。微服務設計原則：1、各司其職 2、服務高可用和可擴充套件性。
微服務架構是從soa架構演變而來的，比soa架構粒度更加精細，讓專業的人，做專業的事，目的是為了提高效率，每個服務於服務之間互不影響，每個服務必須獨立部署(獨立資料庫,獨立redis)，微服務架構更加體現輕量級，採用restful風格提供api，也就是使用http協議+json格式進行傳輸，更加輕巧，更加適合於網際網路公司進行敏捷開發，快速迭代產品。而soa架構採用的是soap協議,也就是http+xml(占用空間大)
乙個微服務只關注乙個特定業務功能，所以**邏輯清晰，**量少，這樣就易於維護，而整個應用是有 多個微服務構建而成。例如：上面的購票系統，使用者模組就需要輔助使用者的業務邏輯，而不用管電影，訂單的業務。
單個服務，**量較少，所以啟動較快。本人之前就遇到過，啟動乙個專案服務花了5分鐘左右，這還是小型系統，如果是大型系統，啟動服務半個小時，也是正常，而一般的外部系統，時時刻刻可能有人在用，所以，一般的部署時間點，都是在凌晨左右，如果中間空缺半個小時左右不能用，我想你的**，要被客戶和公司的人打爆把。
單一應用，只要修改，就得重新部署整個專案，而微服務就不一樣，只需要重新發布修改的那個服務就行，一般這個服務，也不止乙個，案例：例如遊戲的版本1.4 1.5，實際上上線1.5的過程中，1.4版本還是可以正常使用的，這就是因為，該服務不止乙份，也就是說，部署不影響系統的客觀使用。
在微服務中，我們可以根據team掌握的技術，合理的選擇技術
單一應用，只需要打乙個包直接部署就行，而微服務，可能是幾十個或者上百個服務構成乙個應用系統。所以對運維要求較高。
使用微服務構建的是分布式系統，可能存在系統容錯，網路延遲，分布式事務等問題
微服務之間都是通過介面通訊的，如果需要某乙個微服務的介面，可能該服務對應的一系列介面都要更改。
服務之間可能有重複的**，而這部分**，沒有達到需要獨立成乙個服務的程度，所以，會有重複**。
SpringCloud 微服務與微服務對接心德
對方已經提供好乙個api文件，然後傳一堆傳輸，返回給我一些資訊。如下 我這邊建立實體類，返回值這些東西，如下 介面如下 feignclient還有以下標籤 name 指定feignclient的名稱，如果專案使用了ribbon，name屬性會作為微服務的名稱，用於服務發現 url url一般用於除錯...
微服務架構 spring cloud
微服務架構搭建步驟 1.建立服務註冊中心 1 填加依賴 org.springframework.cloudgroupid spring cloud starter eureka serverartifactid dependency org.springframework.cloudgroupid ...
SpringCloud微服務框架
因為springcloud出現,對微服務技術提供了非常大的幫助，因為springcloud 提供了一套完整的微服務解決方案，不像其他框架只是解決了微服務中某個問題.springcloud是基於springboot基礎之上開發的微服務框架，springcloud是一套目前非常完整的微服務解決方案框架，...