微服務架構應用實踐

o6rv196ry 9年前發布 | 12K 次閱讀 微服務

隨著Docker等云技術的大量應用,企業的互聯網業務復雜度不斷提升,傳統整體應用架構模式越來越臃腫,難以適應靈活多變的業務需求。微服務架構(Microservices Architecture)應運而生,它放棄了傳統大規模的單塊集成應用,改為細粒度、松耦合、可靈活組合的自治單元,成為云計算時代應用的主要構建方式。

微服務架構以其高度的彈性、靈活性和效率的巨大提升,快速受到各領域架構師和技術決策者的關注,在Netflix、Amazon、Airbnb等公司成功應用,并逐漸成為互聯網行業最受關注的技術架構。今天就由云智慧開發經理 Allen Lai為大家帶來關于Microservices Architecture微服務架構應用實踐的分享內容。

什么是微服務?

微服務是一種全新的互聯網架構,它的基本理念是將一個肥大的系統拆分成若干小的服務組件,組件之間的通訊采用輕量的協議完成,譬如REST API。微服務本質上是SOA (Serviceoriented Architecture) 的擴展延伸。相對來說,微服務的可操作性更強,可以逐步安排合理資源,對一個大的系統進行分解,或是至少停止讓它繼續肥大。

微服務的好處包括:

  • 按照業務功能的獨立垂直開發機制;

  • 異構開發語言,更多的技術選擇;

  • 高效的部署機制(自動化部署) 和盡可能短的部署周期;

  • 高效的測試機制,易于構建基于服務接口的自動化測試,能盡可能早的發現問題;

  • 面對下游消費者透明,如采用Swagger,可詳細描述輸入,輸出標準(見下圖)。

Restful API集成Swagger1

整體應用 vs 微服務應用

那么,我們來看看另一種過去常用的架構,單體架構Monolithic application的情況,單體架構也有它的優勢,對于項目應用或是公司創業初期是個很好的選擇,可以更快的解決有和沒有的問題,適合小團隊開發實現,而且橫向擴展方便,例如鏡像部署的時候。但當公司大了以后,隨著應用越來越多、第三方系統的不斷接入或者企業的并購,問題會慢慢的暴露出來。

主要體現在如下方面:

  • 功能多了,應用肥大;

  • 接口污染,jar包沖突;

  • 部署困難,任何修改都需部署整體,帶來整體服務downtime;

  • 測試/檢查比較困難,任何修改,切入點過于依賴于從前到后的測試;

  • 問題定位困難,不易找到具體的問題點,通常需要從前到后篩查,或者從海量的og里篩查;

  • 某個服務出現OOM后對整體應用產生影響;

  • 無法通過具體服務對資源的需求搭配硬件資源/網絡資源,只能安裝最高需求整體滿足;

  • 新進人員對開發環境搭建,應用的熟悉需要很長的時間,很難快速通過以點及面的方式切入系統。

我曾經遇到過一個超過400M的大Jar包,啟動應用超過5分鐘,那段時間簡直被OPS罵死。舉個例子,一個產品猶如一條魚,開始的時候游得很暢快,但是有一天,這條魚變成這樣:

整體應用架構

它每次的轉身、變更都很慢,因為太重了。后來我們意識到,不能再往它身上放東西了,經過逐步的調整,變成了如下的結構:

Microservices Architecture

Tomcat上承載的東西變少了,有明確邊界的服務都被拆分成了獨立的restful應用,這樣面向眾多客戶的web app,部署節奏加快,后端的若干子服務部署節奏也加快。

公司大了以后,異構系統和Hybrid都是在所難免的,有朝一日 云智慧 也會面臨這個場景。 監控寶和透視寶 平臺提供的功能由php, java, Ruby on Rails, Python Django, .net mvc等組成,同時對于外部服務的集成,集成后對主應用的影響不亞于功能性的要求。比如集成一個外部服務,他的服務升級很快,那么對這塊功能的變更和主應用應該是隔離的,而微服務架構確實能隔離這個問題。

微服務架構的實現,目前國內有阿里的dubbo,國外有推ter的Finagle框架,他們都是基于RPC的。如果我們的微服務是基于restful服務,那么無須選擇他們,考慮到異構系統,基于http rest依舊是最合適方案。

任何一種架構都有它的適用場景和一些不足,微服務什么問題呢?

  • 需考慮服務間通訊的局部不可用問題。

    假如一個請求需要2個或者多個服務共同組裝數據,某個服務不可用,本質上這個應該取決于業務,具體該請求判決為成功或失敗取決于該故障服務提供的數據權重,比如一個提供商品評論的服務暫時不可用,該數據是次要的。

  • 服務線性依賴問題

    這是個設計問題,從設計上微服務不應該依賴別的業務微服務,如果設計成了服務A—>服務B>服務C..那么帶來的問題會較多。

  • 帶來更多的單點考慮

    采用合理的負載均衡可以解決,但是顯然會帶來部署的復雜性。

  • 應用管理復雜度會上升

這方面,業界也有解決方案,比如Docker / Kubernetes集群化方案。今晚主要是從High level介紹一下微服務架構,具體細節要有合適的應用場景,下次分享我們會準備一個Demo,一起來嘗試如何讓web app更輕,如何用spring boot構建一個微服務。

 

 

來自:https://mp.weixin.qq.com/s/MGA45XfcBGPF5vtUijU7ug

 

 本文由用戶 o6rv196ry 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!