「災難無情人有情」：備戰金三銀四之微服務架構問題！（含解析）

時間 2020-02-22

標籤災難無情有情備戰微服架構問題解析欄目系統架構简体版

原文原文鏈接

前言：

如今IT界跳槽已成常態，跳槽，可能有如下緣由:java

技術達到瓶頸，沒法在此公司有好的提高，前幾年我感受基本不會出現，至少我如今沒出現。
實力與薪資不匹配。
和同事領導不和，若是你在幾家公司都這樣，要自我反省一下是否是本身的問題。

僅我的觀點，其餘諸如地域情感興趣等我的緣由不作討論。node

這也致使不少企業在用人時會比較在乎員工的穩定性通常外包公司都會比較忙，相對來講，成長應該是比較快的，而你的工做性質偏業務，那麼你要想清楚一個問題，之後你的發展軌跡是怎樣的？是在技術方向越走越遠呢，仍是在管理方向發展呢？web

1、微服務架構專題（思惟導圖）

2、微服務是幹什麼的

我對於微服務最大的體會就是：對於雲平臺來講，若是元數據驅動的平臺組件是骨骼，那麼微服務和觸發器就是串聯骨骼的經絡和血脈沒有經絡和血脈，一堆組件僅僅是靜態的，不能變化，沒有反饋，更何談交互。而一個PaaS平臺能夠孵化無數個SaaS應用，每一個應用都須要使用一套小服務來開發，而爲了防止應用搭建複雜化和避免後期難以維護，因此每一個服務運行在本身的進程中，並使用輕量級機制通訊，一般是HTTP AP（Rest的方式，這就是爲何我能看到那些標籤的存在）。好處體如今如下方面：面試

這些服務基於業務能力構建，並可以經過自動化部署機制來獨立部署（體如今平臺就是微服務站點部署和獨立微服務站點部署）
這些服務可使用不一樣的編程語言實現（只要實現結果，無所謂編程語言，這是我認爲如今平臺沒有充分使用到微服務的地方，也多是我平時使用其它語言的業務場景較少）
這些服務可使用不一樣數據存儲技術（「非結構化數據和結構化數據均可以按需存儲」）
這些服務能夠保持最低限度的集中式管理（這個厲害了，至關於接口不只能夠在一個項目裏複用，甚至在不一樣項目間複用）

官方有個2pizza理論頗有趣: 微狹義來說就是體積小、著名的"2 pizza 團隊"很好的詮釋了這一解釋（2 pizza 團隊最先是亞馬遜 CEO Bezos提出來的，意思是說單個服務的設計，全部參與人從設計、開發、測試、運維全部人加起來只須要2個披薩就夠了）。而所謂服務，必定要區別於系統，服務一個或者一組相對較小且獨立的功能單元，是用戶能夠感知最小功能集。spring

3、微服務的特性

每一個微服務可獨立運行在本身的進程裏，一系列獨立運行的微服務共同構建起了整個系統
每一個服務爲獨立的業務開發，一個微服務通常完成某個特定的功能，好比：訂單管理，用戶管理等（我用於圖書管理系統和工單中心）
微服務之間經過一些輕量級的通訊機制進行通訊，例如經過REST API或者RPC的方式進行調用（這就是Rest標籤的由來吧，是一種通訊機制）。

4、微服務的特色

易於開發和維護。因爲微服務單個模塊就至關於一個項目，開發這個模塊咱們就只需關心這個模塊的邏輯便可，代碼量和邏輯複雜度都會下降，從而易於開發和維護。（部署獨立mrest站點，啓動迅速，代碼量小）
啓動較快，這是相對單個微服務來說的，相比於啓動單體架構的整個項目，啓動某個模塊的服務速度明顯是要快不少的。（回收應用程序池便可，不到1分鐘搞定）
局部修改容易部署,在開發中發現了一個問題，若是是單體架構的話，就須要從新發布並啓動整個項目，很是耗時間，可是微服務則不一樣，哪一個模塊出現了bug只須要解決那個模塊的bug就能夠了，解決完bug以後，只須要重啓這個模塊的服務便可，部署相對簡單，沒必要重啓整個項目從而大大節約時間。（有了bug直接hotfix這部分的ESB的interface）
技術棧不受限，好比訂單微服務和電影微服務原來都是用java寫的，如今咱們想把電影微服務改爲nodeJs技術，這是徹底能夠的，並且因爲所關注的只是電影的邏輯而已，所以技術更換的成本也就會少不少。（雖然目前尚未接觸到多語言技術擴展，但感受這個很強）
按需伸縮，單體架構在想擴展某個模塊的性能時不得不考慮到其它模塊的性能會不會受影響，對於微服務來說，徹底不是問題，電影模塊經過什麼方式來提高性能沒必要考慮其它模塊的狀況。