目錄如下 1. 軟體架構的進化 2. 微服務的優勢和不足 3. 微服務架構所帶來的問題及解決方案 1.軟體架構的進化 於筆者經歷來看 架構大致從 單體架構 》MVC 》 微服務 單體架構 單體架構特點在於所有功能業務打包在一個發佈包里，部署在一個web容器中，運行在一個進程里。單體架構的優點在於 容 ...
目錄如下
- 軟體架構的進化
- 微服務的優勢和不足
- 微服務架構所帶來的問題及解決方案
1.軟體架構的進化
於筆者經歷來看 架構大致從
單體架構 》MVC 》 微服務
單體架構
單體架構特點在於所有功能業務打包在一個發佈包里，部署在一個web容器中，運行在一個進程里。單體架構的優點在於- 容易開發 -- 一個人就可以寫了，但是你想想這個後期其他人維護。。。。
- 容易測試 -- 所有功能都在一個進程里嘛，測試就簡單了
- 容易部署 -- 比如一個war包 丟伺服器上就好了
- 維護困難 -- 代碼量之後越來越龐大，新人根本難以上手，不知道經過多少人修改過。。
- 部署困難 -- 隨著代碼變得龐大，部署和啟動的時間也會變長
- 不穩定 -- 牽一發而動全身，一個錯誤就gg
- 擴展不靈活 -- 垂直擴展非常困難
MVC
MVC這個名詞曾經困擾了筆者很久，理解不了這三個英文單詞的含義，筆者後期認為這些名詞拿出來就是迷惑別人的，根本不需去想Model，View，Controller這幾個名詞所代表的含義，只需要知道它的出現解決了代碼雜亂無章，職責不清晰的問題，通過在各層之間定義介面，再將介面與實現分離，可以更好替換實現方案，也更容易讓別人看懂代碼，近期常見的SSM與SSH就是MVC的實現。微服務
什麼是微服務呢？
其實微服務就是一種架構風格。比較官方的定義就是從馬丁大叔的博客中取得
綜合馬丁大叔的這段話，筆者認為微服務主要特點就在於使用一系列微小服務來開發單個應用的方式，每個服務運行在獨立的進程里，一般採用輕量級的通訊互聯機制，並且可以通過自動化的方式部署。
- 一系列微小的服務
- 獨立的進程
- 輕量級的通訊
- 自動化部署
特征在於- 單一職責 -- 例如只有註冊登錄可以放在一個服務里，商品服務就別扔進來了
- 輕量級通訊 -- 語言無關，平臺無關
- 隔離性 -- 運行在自己的進程中
- 獨立數據源 -- 就是有自己獨立的資料庫
- 技術多樣性 --跨語言的嗷~~
2.微服務的優勢與不足
優勢
- 獨立性 -- 每個服務接收到的訪問量也就是QPS是不同的，因為進程獨立的原因，我們可以為其單獨配置硬體環境，修改代碼也不會影響別人
- 敏捷性 -- 可以快速進行開發，每一個微服務都很簡單（不然拆分出來幹啥）
不足
- 如何進行服務拆分 -- 就。。很難
- 數據一致性 -- 不同於單體只有一個資料庫，微服務有很多資料庫（有關這個大家可以去看一下什麼叫CAP理論）
溝通成本 -- 也就是服務間的調用溝通
3.微服務帶來的問題及解決方案
微服務之間如何通訊
1.httpclient進行通訊
2.RPC--遠程過程調用，調用遠程服務和本地服務一模一樣，調用實現對用戶透明微服務之間如何發現彼此
微服務的發現分 服務端發現和客戶端發現，SpringCloud就是服務端發現，Dubbo就是客戶端發現，微服務的發現需要有一個服務發現和註冊中心，即SpringCloud採用的eureka和Dubbo所採用的zookeeper，各個微服務將自己註冊到服務發現註冊中心，服務發現註冊中心將他們記錄之後，通過服務註冊中心，微服務們就可以互相發現和調用彼此。
微服務之間如何部署，擴容，更新
有關此問題將在後面章節中具體闡述，本章只作簡略描述
為解決此問題，我們就必須認識一個名詞叫做服務編排，服務編排就解決了微服務遇到的部署更新和擴容問題，而現在也有許多服務編排的工具例如Mesos，Docker Swarm，Kubernetes等。
