關於微服務的文章，網絡上很多，也比較專業。下面，我嘗試着用簡單的話寫點自己對微服務的理解，非常接地氣，但只是一家之言，大家還是帶着辯證的眼光來讀。
1、微服務的本質是什麼？
微服務的本質是：分而治之。其實這四個字可能用在很多地方，比如模塊的劃分、類的劃分、方法的劃分。在微服務這邊就是進程的劃分，即將不同的業務拆成獨立的進程。
2、微服務會降低項目的複雜度？
會。我所說的”會“是指會降低業務上的複雜度，而不會降低技術上的複雜度，其實，技術上的複雜度會大大增加。原來我們所有的業務都放在一個項目，即一個進程中，業務縱橫交錯，人員變更快，會很快讓一個項目的代碼變得難以維護，比如冗長的類和方法、隨便放的文件夾等等，想想你有多少次想重構代碼的衝動就知道了。業務上如果拆成獨立的服務後，業務關聯少，代碼就會簡單很多，一個服務只處理自己或與之關聯很低的業務。
3、微服務怎麼進行業務拆分？
想要拆分好微服務，首先得對自己所在的項目業務有充分的理解。我們做技術的，非常喜歡追求高大上的技術，而瞧不上公司的增刪改查，覺得寫curd，顯得自己很low。其實，我們可以想一想，你匆匆忙忙寫完curd後，然後去看高大上的技術文章，自己是真提高了還是隻是幻覺？你看的那些，你能落地到你的項目中，幫公司解決實際的業務問題麼？有時候，我們是搞反了。
4、微服務的涉及到的技術棧有哪些？
太多了。以前我們單體應用，建立個三層就可以了，比如一個BS項目，.net使用AspNetMvc即可，java使用ssm或springboot就行。把業務拆成獨立服務後，涉及的技術棧就太多了，比如通信相關的thirft、grpc、http，服務治理相關的consul、eureka等。這些就不一一列舉了，網上文章太多了，這些沒有好的建議，都是和工具相關的，總之多實踐就行，而不是看文章。
5、微服務怎麼部署？
單體服務的時候我們可以使用IIS或tomcat部署，現在拆成多個服務後，比如訂單服務、商品服務、短信服務等，有的服務需要集羣，而有的服務只要單個，需要用到服務註冊發現，本質上其實就要能得到服務的IP和端口就行。微服務後，大家應該都知道的，單機使用docker、docker-compose，集羣使用k8s。
6、微服務通信使用http還是grpc？
建議公網使用http，內網使用grpc。
7、微服務是否需要網關？
需要。業務拆成多個微服務後，比如多個http服務，我們不能將服務直接對外暴露給客戶端，需要添加一個網關層，做數據的聚合，比如訂單列表接口，需要調用訂單服務和商品服務，才能組裝成客戶端需要的數據。網關其實就是webapi，不同的業務有不同的webapi，比如管理後臺調用管理後臺的webapi，移動端調用移動端的webapi。但一些公共的操作，比如登錄、認證、限流等功能，需要每個webapi都要實現一套，爲了將這些操作統一，可以在這些webapi上加一層公共的網關，由網關統一實現上面列舉的功能，並根據規則將客戶端請求路由到對應的webapi，比較出名的有ocelot。
8、老項目需要重構成微服務麼？
不推薦。老項目通常比較穩定，當然，代碼也比較混亂，重構的風險太大。新項目在充分調研後，可以使用微服務。不過提醒一下，微服務涉及的知識非常多，使用需謹慎。
9、總結
微服務最重要的理念就是將複雜龐大的業務拆成一個個簡單清爽的獨立服務，所以一定要先理解自己公司的業務，不能照貓畫虎，記住四個字：分而治之。微服務涉及到的框架工具，建議少看文章，動手操作一遍，也是四個字：知行合一。
如果本文對你有所幫助，就給個“贊”吧！