2018年7月19日，我的處女作《Spring Cloud微服務-全棧技術與案例解析》開賣了。這是一個值得紀念的日子，也是對自己平時學習的考核。

近幾年正是微服務大火的時候，我也算抱了抱大腿，作為一個技術人，必須時刻保持著學習之心，正所謂該出手時就出手。

微服務之所以這麼火，無疑是解決了我們實際工作中遇到的很多痛點。比如重複程式碼多，專案臃腫，啟動時間變長了等問題。

今天主要談談我對微服務的一些理解以及對待技術的態度。

微服務架構是一種架構概念，你可以用Spring Cloud構建，也可以用Dubbo構建，與語言和框架無關。

我眼中的微服務就是拆分，職責單一化。好比一個公司的發展，最開始的幾個人組成的工作室，一個人當3個人用，什麼都要做。後來慢慢發展到50個人了，會劃分出多個部門，每個部門都有自己專注的業務。後面規模更大了之後，一個部門中都會分成很多個小組。我們可以認為每個小組就一個服務，他們專注於某一塊的工作，各個組之間都會有配合。所有小組合起來就是這家公司。

架構也是如此，最開始一個專案，什麼功能都往裡面加，到後面程式碼量多，功能複雜，一出問題影響整個系統，相比上面的公司也是一樣，如果沒有嚴格的部門劃分，職責劃分，那很有可能就亂成一鍋粥了。我也不是什麼專家，說的也不一定對，大家就隨便理解下吧。

微服務並沒有大家想象中的那麼神祕，大公司可以做，小公司同樣可以。能不能成功實施微服務，取決於你們的技術負責人和各位自己對待技術的態度。

我其實是一個比較開放的人，不會一直封閉在僅有的一些老技術中，喜歡也願意嘗試著在工作中去使用新的技術框架。

一個好的框架用起來會得心應手，提高開發效率。最重要的是得跟上潮流，技術更新太快，作為一位開發人員，只能不斷的去學習才能不被淘汰。

最近有看過一篇文章，叫為什麼很多大公司還在用老技術？這種就是公司層面的問題了，重構成本太高。還有一種說法就是脫離業務的技術架構都是耍流氓，確實如此，合適的時機做合適的事情。

上面說的我覺得都沒有錯，你的領導上面有公司的壓力，不會說為了用一些新技術去費很高的成本去做重構這件事情。

但是，站在一位普通開發者的角度考慮，如果一直用老技術，當你換工作的時候就會發現落後了很多。當然你也可以自己努力點，自己學習，面試官會說你沒實戰經驗。不是我想學，而是現實如此。

我還是鼓勵大家勇敢的去嘗試新的技術，遇到困難不可怕，可怕的是你沒解決困難的機會，只有不斷踩坑，才能成就優秀的你。

中小型團隊玩微服務，不要太多高大上的功能，夠用，能夠支援業務的發展就行了。就以限流來說，如果你們的產品沒多大的訪問量，說實話，限流與不限流沒什麼區別，何必浪費這麼多時間來做限流這事情，把時間花在完善產品的功能上不是更好。

當然也不是說限流就不重要了，萬一有突發情況，萬一業務發展太快，請求量暴增，系統頻頻被沖垮，這個時候限流就很重要了，我想表達的只是對的時間做對的事，有條件的情況下未雨綢繆必須先做起來。

在實施的過程中，我們可以借鑑一些優秀公司已經成功的案例，結合公司本身的業務設計出符合業務發展的架構，結合公司的技術棧選擇合適的框架來構建微服務。

正所謂‘兵馬未動,糧草先行’，公司未動，自我先行。極客時間最新推出了《從0開始學微服務》專欄，由新浪微博架構師胡忠想老師給大家分享微服務架構過程的經驗和感悟。

我仔細看了課程大綱，內容非常全面。總共分為四個模組，每個模組的內容都非常多，知識面廣。

• 模組一
  主要講解了微服務基礎原理，對微服務進行了深度剖析，讓你知道什麼是微服務，如何做監控，追蹤等知識點。並且會以Dubbo為例，剖析微服務架構的具體實現。

• 模組二
  模組二的內容就是完完全全的實戰，可以稱之為‘微服務最佳實踐’。其中包括對註冊中心，RPC框架的選型建議。服務端故障，客戶端呼叫失敗等處理手段。

• 模組三
  講的是微服務怎麼做Docker容器化與DevOps。通過容器化和DevOps簡化釋出流程，構建彈性伸縮架構。

• 模組四
  對微服務的展望，未來的微服務會是什麼樣子？會帶給我們怎樣的驚喜。作為下一代微服務架構Service Mesh當仁不讓，我也非常期待胡老師眼中的Service Mesh是怎樣的。

我自己也買了，學習學習前輩的優秀經驗。各位讀者朋友如果有興趣，歡迎長按識別海報的二維碼購買，價格還是比較合適的。貌似大家購買了我會有返現金額，有購買的朋友可以告訴我，等返現給我了，我再退回給大家，降低大家的學習成本。

胡老師的個人介紹

胡忠想，微博服務化專案架構師&技術負責人，2012年加入微博工作至今，承擔過微博計數器架構升級，春晚和奧運服務保障，以及微博feed業務架構升級等工作。目前，主要專注於服務化方向，工作內容包括：微服務治理，彈性排程以及自動化監控等。