我們平時總說微服務、微服務恒削、那么究竟什么是微服務呢池颈？微服務跟傳統(tǒng)的項目服務有什么區(qū)別呢尾序？今天我們來一探究竟。
單體式架構
先來看看單體式架構：它的概念就是將項目的代碼都合歸一處躯砰。如果項目很小的時候特別靈活每币。但是如果項目大起來的話，必然會帶來一定的缺點：
1.項目迭代不靈活
2.項目組職責琢歇、權限不清
3.項目并發(fā)配置不靈活
4.項目部署擴展困難
微服務架構
微服務架構的核心觀念就是“拆”兰怠，拆什么呢？就是將項目拆分幾個獨立的功能單元（服務）的架構
必有其優(yōu)點：
1.項目復雜度降低
2.團隊界限明確
3.部署靈活
具體場景具體應用：
下面來看看什么樣的產品用什么架構比較合適：
常見的微服務框架
1.Dubbo/Dubbox
由阿里巴巴開發(fā)李茫、當當網改良揭保，基于RPC服務
2.Spring Cloud
由Spring團隊開發(fā)，基于RESTful
微服務架構-服務類型
1.Provider
提供者魄宏，提供服務的一方
2.Consumer
消費者秸侣，調用服務的一方
微服務架構-通信方式
1.RPC
全稱：Remote Procedure Call
支持RPC的微服務框架：Dubbo/Dubbox
基于TCP、與平臺有關
2.RESTful
全稱：Representational State Transfer
支持RPC的微服務框架：Spring Cloud/Dubbox
基于HTTP宠互、與平臺無關
微服務架構-設計原則
1.單一職責原則
對一個項目拆分的時候味榛，每一個項目只能包含這一個項目的業(yè)務，而不能包含其他項目的業(yè)務
2.圍繞業(yè)務切分
不能隨意切分名秀，盡量一個業(yè)務拆成一個項目
3.誰創(chuàng)建誰負責
在實際工作中励负，用到微服務肯定是因為用戶量非常大， 技術團隊也很多匕得，比如用戶模塊继榆，是A團隊創(chuàng)建的就不能讓B團隊插手開發(fā)和部署的事情。這一塊與devops理念很相似汁掠。
其他概念
分布式
對于分布式略吨，它更加關注的是項目的拆分，對于一個大項目而言考阱，有ABC三個模塊翠忠，分布式就是將這個大項目拆分為A項目、B項目乞榨、C項目秽之，而除了這種垂直性的拆分，還有可能對每一個子項目進行分層吃既，使得業(yè)務更具體考榨。分布式其實就是拆分，分為垂直拆分和分層規(guī)劃鹦倚。
集群
集群更加關注的是項目的部署河质，也是同樣的一個項目，當用戶量不是很多的時候，部署一個服務器是沒問題的掀鹅，但是當用戶量龐大起來的時候散休，服務器壓力頂不住了，我們就可以將這一個項目部署成三個服務器乐尊，不管是輪詢訪問也好戚丸，隨機訪問也好，都將其稱之為集群扔嵌。
