戳藍字“CSDN云計算”關注我們哦！

微服務(Microservice Architecture)是近幾年流行的一種架構思想,關于它的概念很難一言以蔽之。今天，就讓我們來看看關于微服務更加有深度的問題吧。

1

? ? Q：什么是微服務

? A：1）一組小的服務（大小沒有特別的標準，只要同一團隊的工程師理解服務的標識一致即可）

2）獨立的進程（java的tomcat，nodejs等）

3）輕量級的通信（不是soap，是http協議）

4）基于業務能力（類似用戶服務，商品服務等等）

5）獨立部署（迭代速度快）

6）無集中式管理（無須統一技術棧，可以根據不同的服務或者團隊進行靈活選擇）

ps：微服務的先行者Netflix公司，開源了一些好的微服務框架，后續會有介紹。

2

? Q：怎么權衡微服務的利于弊

? A：利：

強模塊邊界 。（模塊化的演化過程：類-->組件/類庫（sdk）-->服務(service)，方式越來越靈活）

可獨立部署。

技術多樣性。

弊：

分布式復雜性。

最終一致性。（各個服務的團隊，數據也是分散式治理，會出現不一致的問題）

運維復雜性。

測試復雜性。

3

Q：企業在什么時候考慮引入微服務

? ?A：從生產力和系統的復雜性這兩個方面來看。公司一開始的時候，業務復雜性不高，這時候是驗證商業模式的時候，業務簡單，用單體服務反而生產力很高。隨著公司的發展，業務復雜性慢慢提高，這時候就可以采用微服務來提升生產力了。至于這個轉化的點，需要團隊的架構師來進行各方面衡量，就個人經驗而言，團隊發展到百人以上，采用微服務就很有必要了。

?

有些架構師是具有微服務架構能力，所以設計系統時就直接設計成了微服務，而不是通過單服務慢慢演化發展成微服務。在這里我并不推薦這種做法，因為一開始對業務領域并不是很了解，并且業務模式還沒有得到驗證，這時候上微服務風險比較高，很有可能失敗。所以建議大家在單服務的應用成熟時，并且對業務領域比較熟悉的時候，如果發現單服務無法適應業務發展時，再考慮微服務的設計和架構。

4

Q：微服務的組織架構

? ?A：如下圖左邊，傳統的企業中，團隊是按職能劃分的。開發一個項目時，會從不同的職能團隊找人進行開發，開發完成后，再各自回到自己的職能團隊，這種模式實踐證明，效率還是比較低的。

如上圖右邊，圍繞每個業務線或產品，按服務劃分團隊。團隊成員從架構到運維，形成一個完整的閉環。一直圍繞在產品周圍，進行不斷的迭代。不會像傳統的團隊一樣離開。這樣開發效率會比較高。至于這種團隊的規模，建議按照亞馬遜的兩個披薩原則，大概10人左右比較好。

5

Q：怎么理解中臺戰略和微服務

? ?A：中臺戰略的由來：馬云2015年去歐洲的一家公司supersell參觀，發現這個公司的創新能力非常強，團隊的規模很小，但是開發效率很高。他們就是采用中臺戰略。馬云感觸很深，回國后就在集團內部推出了中臺戰略。

簡單的理解就是把傳統的前后臺體系中的后臺進行了細分。阿里巴巴提出了大中臺小前臺的戰略。就是強化業務和技術中臺，把前端的應用變得更小更靈活。當中臺越強大，能力就越強，越能更好的快速響應前臺的業務需求。打個比喻，就是土壤越肥沃，越適合生長不同的生物，打造好的生態系統。

小伙伴們沖鴨，后臺留言區等著你！

關于微服務，今天你學到了什么？還有哪些不懂的？除此還對哪些話題感興趣？快來留言區打卡啦！留言方式：打開第XX天，答：……

同時歡迎大家搜集更多問題，投稿給我們！風里雨里留言區里等你~

重磅推薦↓ ↓ ↓

福利

掃描添加小編微信，備注“姓名+公司職位”，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！

推薦閱讀：

• 蘋果宣布加入CNCF；華為要求美國運營商支付專利費；微軟刪除最大的公開人臉識別數據集

• 如何給老婆解釋什么是微服務？
  

• 阿里巴巴楊群：高并發場景下Python的性能挑戰

• 那些去德國的程序員后來怎么樣了？

• 新技術“紅”不過十年，半監督學習為什么是個例外？

• 獨家對話V神! 質疑之下的以太坊路在何方?
  

真香，朕在看了！

總結

以上是生活随笔為你收集整理的微服务精华问答 | 如何理解中台战略和微服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。