要上微服務，先考慮好這幾點再說

2020-08-26 一起web編程

今天一個朋友問我，我想做一個項目，兩年內做到1000w用戶量，並發數1000左右，需要用微服務嗎？


最近不知道什麼時候，微服務一下火了起來，人人在說微服務，很多公司都在用微服務，

今天就來討論一下，是所有項目都適合微服務嗎

1.什麼是微服務

微服務應該是從java那邊傳過來的，java的spring boot、dubbo，然後golang的go-micro,

就連php也有了微服務，phper肯定不滿啦，PHP咋了，作為世界上最好的語言，怎麼就不能有微服務！

哈哈，其實我也是一個phper。

一般情況下，我們項目初期都是單體架構，好處是簡單，易開發、易維護、易排查，還有易交接，

可是隨著功能越來越多，越來越複雜，例如一個系統有用戶模塊，商戶模塊，訂單模塊，認證模塊等，系統需要提供

web api，移動 api，後臺api等


mvc


這時候，把系統功能按模塊拆分開，把原來大而全的單體應用拆分成功能獨立的、自洽的小而美的多個應用的組合。這就是微服務

每個服務負責自己模塊的功能，獨立開發、運維、部署、維護，互不幹擾，用什麼語言，採用什麼架構自己說了算，相互之間可以通過協議通信


micro

2.微服務的利弊

先說好處：

a. 服務分治，相互獨立，可獨立技術棧，DB設計，更高的自主性；

b. 每個服務做到高耦合，外部接口交互數據，可擴展性強；

c. 有利於對抗高並發，性能較好；


不要以為用了微服務就萬事大吉了，能把微服務安全落地，穩定跑起來可不是容易的事情，凡事有利就有弊，說下弊端：

a. 開發、測試、運維難度增加，本來一次搞定的，卻要分開多個，每個都要來一遍，誰能不崩潰！


b. 穩定性差，調用鏈複雜，一個崩潰，一個性能差，可能影響多個業務；保證自己沒問題，但保證不了別人的服務沒問題呀！

c. 出現錯誤排查難度增加，定位不準，不同的團隊之間，就會相互推諉！

這時就需要一個監控系統，監控系統每個組件的運行情況啦！

總之，搭建微服務，需要強大的配套系統才能穩定的跑起來。


業界對微服務的應用也是褒貶不一，用好了是一大利器，用不好就是找死，目前沒有點實力的公司還是很難玩的溜。所以用不用要謹慎，想用前考慮好服務粒度細、體系架構複雜、開發效率低、服務治理難，監控維護難這些問題，用微服務，道路是曲折的，前途也不一定是光明的，也許就是一條不歸路。


3. 需要考慮哪些？

a. 服務拆分，拆分是一個很麻煩 的活，系統內部可能有千絲萬縷的聯繫，相互調用，如常見的連表，拆不好內部就是一團亂麻，難以維護，充分考慮自己的需求，合理拆分！分布式的數據強一致性，也是業界 的難題


b. 選好語言，找一個跟自己需求匹配度高的框架，這樣可以省很多事。目前微服務這塊java可能是首選。


網上很多文章把微服務說的很高大上，但是能用好可不是容易的事情。

因為微服務架構本身的複雜性，初創公司系統出於快速開發、快速驗證的考慮，很少在一開始就使用微服務架構，後面看情況要不要用微服務。要用微服務，首選把分布式系統穩定跑起來再說吧。畢竟不是所有系統都適合，何必拿大炮打蚊子呢。

微服務都是逐步演進的，不是一蹴而就的，演化思路應該是一步步鋪基礎設施，一點點拆分微服務。

微服務是一個很大的話題，裡面的內容可以寫一本書了，所以很難把細節將清楚。本篇文章就當做是概念介紹吧！

相關焦點

  • 「微服務」 關於微服務的幾點老闆關心問題
    回答關於微服務的幾點老闆關心問題單體系統在初期可以實現比較方便地開發與使用，但是隨著系統的發展，維護成本變大，且難以控制（當一個系統業務複雜且架構設計不合理，同時以前的開發者之間沒有什麼規範的時候，後續新人對於功能的修改、維護、完善都必須建立在對系統整體業務的把握上，這也對開發人員提出了更高要求）。
  • 微服務治理實踐：服務契約
    本文是《微服務治理實踐》系列篇的第四篇文章，主要分享Spring Cloud微服務框架下的服務契約。第一篇：《微服務治理解密》第二篇：《微服務治理實踐：服務查詢》第三篇：《微服務治理實踐：金絲雀發布》在詳細講述服務契約之前，先給大家講一個場景。
  • 數據治理、中臺、微服務,這三者怎麼扯上關係的?
    老闆交代：「要搞一個數據中臺架構，涵蓋數據資產管理、數據治理、數據分析等，同時這個數據中臺，要體現去中心化，甚至無中心化的理念」。　　我這哥們兒有過多年的數倉架構經驗，並參考了業界主流的數據中臺架構，很快就「照貓畫虎」的搞了一個數據中臺架構圖出來。
  • 淨水器哪個牌子好?如何擇優購買要考慮這幾點
    淨水器哪個牌子好？如何擇優購買要考慮這幾點 2019年09月12日 13:51作者：網絡編輯：宏偉 　　淨水器品牌眾多，不同品牌的同類產品在結構上大同小異，它們的濾芯功能也是一樣。
  • 零基礎學java，這幾點你要先了解！
    小編從企業的需求簡單總結了以下幾點，供同學做個參考的方向。1、技術要求：（學習的重點）①精通JavaEE、資料庫、緩存、消息隊列、索引等技術；②精通分布式架構，熟悉主流的微服務框架，如SpringCloud、Dubbo、Zookeeper等，並精通其原理；③精通linux常用命令，網絡協議，jvm
  • 微服務挺好，但你真的適合嗎？
    遇到問題再說，那就晚了，對於架構師來說，頂多就是再換個老闆，但對於企業來說，很有可能就是沒了。微服務真挺好的，但是在你決定做之前，請做充足的調研，確認自己是否真的適合？因此在技術改革時，需要考慮自己的業務是否需要快速迭代？自己的底層能力建設如何？不要本末倒置。
  • 進行微服務治理，先要對微服務進行度量
    要管得到，必須先看得到！要對微服務進行治理，先要對微服務進行度量。根據微服務的生命周期，可以將服務度量分為服務開發質量度量、服務測試質量度量、服務運維質量度量和服務線上性能度量四大部分。這類關係圖對我們快速梳理和理解系統的邏輯非常有幫助，在此基礎上也可以對微服務的調用質量進行優化。源碼是一個寶庫，包含了很多的內容。假如有個「超人」能夠記住所有的源碼並理解透徹，那麼很多治理的難題都能迎刃而解。問題一出來，超人就能快速地定位問題所在。
  • 如何從傳統springmvc架構逐步遷移到微服務架構
    最近在技術圈子聊到個關於微服務的話題，存在不少爭議，很多人覺得微服務框架根本用不上，但是出去外面找工作面試，不會微服務又基本處於java後臺技術文盲。如果有以下幾點場景，建議可以開始規劃微服務架構設計：1.對微服務技術感興趣的人員；2.希望找到一份較好的技術崗位的人；3.對當前項目想做大做強的項目，就提前考慮架構設計的架構師；4.當前單體架構已經不滿足實際業務場景，不得不做技術的升級改造；下面我就講解下如何從傳統springmvc架構可以逐步無縫遷移到微服務架構
  • 微服務實踐之路--RPC
    而我的想法是要跟Dubblo、HSF的用法一樣，因為很多人都熟悉這兩個框架的用法，特別是我們好幾個項目都是基於EDAS開發的，而且世面上用Dubbo的公司也很多。順便再說一下我們對於RPC的幾點要求：1，兼容Dubbo和HSF的使用方法，支持版本和服務分組，支持項目隔離2，客戶端重試機制，可以配置次數和間隔時間3，客戶端線程池4，服務端可以平滑無縫升級而不影響客戶端的使用兼容Dubbo就必然要使用Spring框架，那我們就直接上Spring Boot好了，號稱Spring Boot為微服務開發而生，一步到位，將Thrift跟Spring Boot
  • 「女人要對自己好一點!」,沒錢的女人,請先賺錢再說這句話
    都說女人要對自己好一點。其實哪個女人不想對自己好一點？高檔的化妝品，大牌的包包，高檔補品，漂亮的服裝……通通都想要。可是對自己好，是要有資本的，是需要有經濟基礎支撐的。當你自己沒有錢又不會賺錢，拿什麼對自己好？
  • 面試不會微服務沒關係，跟著我4天學會微服務
    而Martin Fowler大師《重構》一書中有說過一句話，大概意思就是，「每次對原有系統進行修改調整的時候是一個非常好的重構契機。，這是一個契機，無論怎麼樣，最終隨著主體業務的複雜化，終會以各種不同的形式靠攏其中那無論是出於面試還是知識點的學習，我想，對於微服務，學習一下，對你後期一定會有一些幫助day1隨著網際網路的發展，網站應用的規模不斷擴大，常規的應用架構已無法應對，分布式服務架構以及微服務架構勢在必行
  • 極品攻略文:想寵我,先追上我再說,我再開始考慮
    大家好，小編又來推薦優質文章了，今天給大家推薦極品攻略文：想寵我，先追上我再說，我再開始考慮。最近鬧書荒的寶寶們，給你們送來驚喜，今天就來看看小編推薦的幾部小說，保證讓你意猶未盡，身臨其境。1、《攻略極品》作者：薩琳娜文案：(好吧，極品就極品，只要能拿到獎勵、能讓自己變強，安妮咬牙拼了。）已經整整一天了！
  • SpringCloud微服務部署與發布:部署微服務面臨的挑戰
    例如，在天氣預報系統中，天氣預報微服務是依賴於天氣數據API微服務及城市數據API微服務的，只要這兩個數據API微服務其中一個不可用，則會導致整個天氣預報微服務不可用。所以在更新服務時，需要先確定哪些服務需要更新，而後評估更新對其他服務的影響是什麼。 3.更多的監控 每個微服務往往需要設置單獨的監控，這意味著更多的監控。
  • SpringCloud微服務部署與發布：部署微服務面臨的挑戰
    例如，在天氣預報系統中，天氣預報微服務是依賴於天氣數據API微服務及城市數據API微服務的，只要這兩個數據API微服務其中一個不可用，則會導致整個天氣預報微服務不可用。所以在更新服務時，需要先確定哪些服務需要更新，而後評估更新對其他服務的影響是什麼。3.更多的監控每個微服務往往需要設置單獨的監控，這意味著更多的監控。
  • 微服務的理想與現實
    可以這樣理解，微服務架構也是SOA架構分布式化的一種實現方式。它的優勢在於小而治之、去中心化，但與之對應的問題是，你要管理越來越多的微服務。而如何進行微服務拆分和服務治理，是十分考驗能力的試金石。 縱觀前後，服務架構歷次的迭代更新，都是圍繞著用戶如何節約成本和提升效率，來解決不斷出現的新問題，微服務就是服務架構演進史的產物之一。
  • 學微服務看這篇，大廠老兵從「四個維度」講明白什麼是微服務
    微服務強調的是基於業務功能構建，業務功能之間要鬆散耦合，有明確邊界。然後，對於一個複雜業務系統，在設計早期要做的這點並非易事。根據墨菲定律--「凡是可能出錯的那它一定會出錯」，選擇微服務就一定會遇到上述我說的這些問題。
  • 微服務還沒徹底普及，宏服務又要來了？
    但是從github上的數據顯示已經很明顯了，基本上大多數公司不是已經用了微服務，就是還在使用微服務的路上。不過凡事有利就有弊，微服務也不是十全十美的，這不就因為某些缺點，Uber就開始使用了宏服務。）硬體成本高五個微服務可能需要佔據10個進程，如果要加入負載均衡和監控機制等等，需要的進程就更多了，這對於一些運維的硬體設施來說，成本真的太高了。
  • 飼養倉鼠,一定要注意好這幾點
    飼養倉鼠，一定要注意好這幾點。我想大家聽到倉鼠應該一點也不會陌生吧！倉鼠是現在較為流行的一種小寵物，大家有你沒有覺得它小小隻的特別的可愛，很多人對於倉鼠的可愛可是會一見鍾情的，一直以為可愛活潑的倉鼠一直就深受著大眾的喜愛，特別是女孩。今天我要來告訴大家幾點關於養倉鼠的注意事項。
  • 首先你要考慮這幾點
    在講之前，先普及一下，可能很多人沒有意識到這樣一個事實。那就是智能插座是最被低估的智能家居產品之一。的確，智能插座不是最閃亮的智能家居產品，但它們可以輕鬆地將你家裡的非智能電器變得更加智能化。如果你準備購買智能插座，並將它們加入到你的智能家居系統。為了確保最適合自己，請在購買之前先考慮以下內容。
  • 2018年選360全景品牌,一定要先看看這家再說
    時間如白駒過隙，很快進入了2018年，360全景項目怎麼做，似乎成了很多後市場老闆躲不過去的話題，什麼樣才是好的360全景項目呢？根據不少行業人士的反饋和分享，探長360汽車黑匣子受到很多人的認可。要選擇360全景項目的朋友，一定要先看看探長再說。