1、什么是微服務
????????微服務（或稱微服務架構）是一種云原生架構方法，在單個應用中包含眾多松散耦合且可單獨部署的小型組件或服務。 這些服務通常擁有自己的技術棧，包括數據庫和數據管理模型；通過一個REST API、事件流和消息代理組合彼此通信；以及按照業務能力進行組織，具有通常稱為有界上下文的服務分隔線。
2、為什么要使用微服務
? ? ? ? 為什么要使用微服務，這個就要結合服務的進化歷史來說一說。
2.1、單實例單數據庫的單體架構
? ? ? ? 早期的項目，所有數據都保存在一個數據庫中，所有的服務都在集中在一套代碼中，服務上安裝好數據庫和運行環境后，部署上對應的系統，即可以進行使用。
2.2、多實例單數據庫的單體架構
? ? ? ? 隨著系統用戶量增加，單實例單數據庫的單體架構就會出現問題，比如訪問延遲、響應過慢等問題，所以，此時就會來增加服務器，使用負載均衡來提高服務性能，緩解單節點服務的壓力。
2.3、多實例多數據庫的單體架構
? ? ? ? 數據量再次擴大后，數據庫的訪問就會出現問題，此時，就會再增加數據庫的實例，將新增、修改、刪除等操作與查詢操作分離，實現多個數據庫訪問，并實現數據庫的主從復制。
2.4、SOA?架構
? ? ? ? 當項目需要擴展新需求時，在原來的基礎上進行增加和修改，就會影響到之前的業務，那么如何處理呢，就需要引入消息總線ESB總線，將原來的服務與新的服務分開，用消息總線來進行通信。兩個部分分開處理，互相不影響。
2.5、微服務架構
????????項目逐漸變得越來越龐大，開發人員也越來越多，團隊達到了大幾十人。這時，就會發現原來的服務拆分粒度太 “粗”，而且原先系統的所有流量都會經過?ESB?進行分發，造成系統的可用性下降，甚至在流量峰值出現部分節點宕機的情況，這是一大隱患。
????????于是， 就需要進一步拆分團隊，拆分服務，將原先的服務與其他服務又進行了拆分，拆出了 10 余個服務。為了治理這些服務，就需要引入微服務架構，用微服務網關與注冊中心代替原有的消息總線，并采用分布式部署。除此之外，一系列微服務治理框架與?Devops 自動化運維部署流程也隨之引入，每一個微服務均通過容器化方式部署上線。
3、總結
- 單體架構：所有功能都集中在同一個項目內，統一測試，統一部署，牽一發而動全身，適合初創項目進行試錯，不適合大型商業項目。
- 在此基礎做的縱向升級、橫向擴容、一主多從等仍然屬于單體架構，因為其仍然是單一服務、單一項目。
- SOA 架構：進行了初步的服務拆分，但是服務拆分的粒度較粗，并且沒有引入服務治理組件，流量集中于消息總線。
- 微服務架構：是 SOA 架構的升級，基本沿用了 SOA 的思想，但是服務拆分粒度更細，并且引入了服務治理組件，結合流行的容器化技術，實現?Devops?自動化部署與運維。
- Devops（Development和Operations的組合詞）?是一組過程、方法與系統的統稱，用于促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。總是與微服務一起出現，因為 Devops 帶來的是敏捷開發、更快交付，而微服務通常由各個小團隊負責開發，迭代周期更快、更敏捷。
- CI/CD?是?Devops?的核心，CI/CD 是一種通過在應用開發階段引入自動化來頻繁向客戶交付應用的方法，CI/CD 的核心概念是持續集成、持續交付和持續部署。它是作為一個面向開發和運營團隊的解決方案，主要針對在集成新代碼時所引發的問題（也稱為：“集成地獄”）。
)
)
