国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

如何快速搭建一個微服務架構

MockingBird / 1700人閱讀

摘要:如何快速搭建一個微服務架構上圖異步通信方式通常異步的生產(chǎn)者消費者模式,通過等異步消息通訊協(xié)議規(guī)范。數(shù)據(jù)的去中心化,進一步降低了微服務之間的耦合度,不同服務可以采用不同的數(shù)據(jù)庫技術等。

什么是微服務?

微服務(Microservices Architecture)是一種架構風格,一個大型復雜軟件應用由一個或多個微服務組成。系統(tǒng)中的各個微服務可被獨立部署,各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。在所有情況下,每個任務代表著一個小的業(yè)務能力。

微服務的概念源于2014年3月Martin Fowler所寫的文章“Microservices” martinfowler.com/articles/mi…

單體架構(Monolithic Architecture )

企業(yè)級的應用一般都會面臨各種各樣的業(yè)務需求,而常見的方式是把大量功能堆積到同一個單體架構中去。比如:常見的ERP、CRM等系統(tǒng)都以單體架構的方式運行,同時由于提供了大量的業(yè)務功能,隨著功能的升級,整個研發(fā)、發(fā)布、定位問題,擴展,升級這樣一個“怪物”系統(tǒng)會變得越來越困難。

這種架構模式就是把應用整體打包部署,具體的樣式依賴本身應用采用的語言,如果采用java語言,自然你會打包成war包,部署在Tomcat或者Jetty這樣的應用服務器上,如果你使用spring boot還可以打包成jar包部署。其他還有Rails和Node.js應用以目錄層次的形式打包

上圖:單體架構

大部分企業(yè)通過SOA來解決上述問題,SOA的思路是把應用中相近的功能聚合到一起,以服務的形式提供出去。因此基于SOA架構的應用可以理解為一批服務的組合。SOA帶來的問題是,引入了大量的服務、消息格式定義和規(guī)范。

多數(shù)情況下,SOA的服務直接相互獨立,但是部署在同一個運行環(huán)境中(類似于一個Tomcat實例下,運行了很多web應用)。和單體架構類似,隨著業(yè)務功能的增多SOA的服務會變得越來越復雜,本質上看沒有因為使用SOA而變的更好。圖1,是一個包含多種服務的在線零售網(wǎng)站,所有的服務部署在一個運行環(huán)境中,是一個典型的單體架構。

單體架構的應用一般有以下特點:

設計、開發(fā)、部署為一個多帶帶的單元。

會變得越來越復雜,最后導致維護、升級、新增功能變得異常困難

很難以敏捷研發(fā)模式進行開發(fā)和發(fā)布

部分更新,都需要重新部署整個應用

水平擴展:必須以應用為單位進行擴展,在資源需求有沖突時擴展變得比較困難(部分服務需要更多的計算資源,部分需要更多內存資源)

可用性:一個服務的不穩(wěn)定會導致整個應用出問題

創(chuàng)新困難:很難引入新的技術和框架,所有的功能都構建在同質的框架之上

運維困難:變更或升級的影響分析困難,任何一個小修改都可能導致單體應用整體運行出現(xiàn)故障。

微服務架構(Microservices Architecture)

微服務架構的核心思想是,一個應用是由多個小的、相互獨立的、微服務組成,這些服務運行在自己的進程中,開發(fā)和發(fā)布都沒有依賴。不同服務通過一些輕量級交互機制來通信,例如 RPC、HTTP 等,服務可獨立擴展伸縮,每個服務定義了明確的邊界,不同的服務甚至可以采用不同的編程語言來實現(xiàn),由獨立的團隊來維護。簡單的來說,一個系統(tǒng)的不同模塊轉變成不同的服務!而且服務可以使用不同的技術加以實現(xiàn)!

上圖:微服務架構

微服務設計

那我們在微服務中應該怎樣設計呢。以下是微服務的設計指南:

職責單一原則(Single Responsibility Principle):把某一個微服務的功能聚焦在特定業(yè)務或者有限的范圍內會有助于敏捷開發(fā)和服務的發(fā)布。

設計階段就需要把業(yè)務范圍進行界定。

需要關心微服務的業(yè)務范圍,而不是服務的數(shù)量和規(guī)模盡量小。數(shù)量和規(guī)模需要依照業(yè)務功能而定。

于SOA不同,某個微服務的功能、操作和消息協(xié)議盡量簡單。

項目初期把服務的范圍制定相對寬泛,隨著深入,進一步重構服務,細分微服務是個很好的做法。

微服務消息

在單體架構中,不同功能之間通信通過方法調用,或者跨語言通信。SOA降低了這種語言直接的耦合度,采用基于SOAP協(xié)議的web服務。這種web服務的功能和消息體定義都十分復雜,微服務需要更輕量的機制。

同步消息 REST

同步消息就是客戶端需要保持等待,直到服務器返回應答。REST是微服務中默認的同步消息方式,它提供了基于HTTP協(xié)議和資源API風格的簡單消息格式,多數(shù)微服務都采用這種方式(每個功能代表了一個資源和對應的操作)

異步消息 – AMQP, STOMP, MQTT

異步消息就是客戶端不需要一直等待服務應答,有應到后會得到通知。某些微服務需要用到異步消息,一般采用AMQP, STOMP, MQTT 這三種通訊協(xié)議

消息格式 – JSON, XML, Thrift, ProtoBuf, Avro

消息格式是微服務中另外一個很重要的因素。SOA的web服務一般采用文本消息,基于復雜的消息格式(SOAP)和消息定義(xsd)。微服務采用簡單的文本協(xié)議JSON和XML,基于HTTP的資源API風格。如果需要二進制,通過用到Thrift, ProtoBuf, Avro。

服務約定 – 定義接口 – Swagger, RAML, Thrift IDL

如果把功能實現(xiàn)為服務,并發(fā)布,需要定義一套約定。單體架構中,SOA采用WSDL,WSDL過于復雜并且和SOAP緊耦合,不適合微服務。

REST設計的微服務,通常采用Swagger和RAML定義約定。

對于不是基于REST設計的微服務,比如Thrift,通常采用IDL(Interface Definition Languages),比如Thrift IDL。

微服務集成 (服務間通信)

大部分微服務基于RPC、HTTP、JSON這樣的標準協(xié)議,集成不同標準和格式變的不再重要。另外一個選擇是采用輕量級的消息總線或者網(wǎng)關,有路由功能,沒有復雜的業(yè)務邏輯。下面就介紹幾種常見的架構方式。

點對點方式

點對點方式中,服務之間直接用。每個微服務都開放REST API,并且調用其它微服務的接口。

上圖:通過點對點方式通信

很明顯,在比較簡單的微服務應用場景下,這種方式還可行,隨著應用復雜度的提升,會變得越來越不可維護。這點有些類似SOA的ESB,盡量不采用點對點的集成方式。

API-網(wǎng)關方式

API網(wǎng)關方式的核心要點是,所有的客戶端和消費端都通過統(tǒng)一的網(wǎng)關接入微服務,在網(wǎng)關層處理所有的非業(yè)務功能個。通常,網(wǎng)關也是提供REST/HTTP的訪問API。服務端通過API-GW注冊和管理服務。

上圖:通過API-網(wǎng)關暴露微服務

所有的業(yè)務接口通過API網(wǎng)關暴露,是所有客戶端接口的唯一入口。微服務之間的通信也通過API網(wǎng)關。

采用網(wǎng)關方式有如下優(yōu)勢:

有能力為微服務接口提供網(wǎng)關層次的抽象。比如:微服務的接口可以各種各樣,在網(wǎng)關層,可以對外暴露統(tǒng)一的規(guī)范接口。

輕量的消息路由、格式轉換。

統(tǒng)一控制安全、監(jiān)控、限流等非業(yè)務功能。

每個微服務會變得更加輕量,非業(yè)務功能個都在網(wǎng)關層統(tǒng)一處理,微服務只需要關注業(yè)務邏輯

目前,API網(wǎng)關方式應該是微服務架構中應用最廣泛的設計模式。

消息代理方式

微服務也可以集成在異步的場景下,通過隊列和訂閱主題,實現(xiàn)消息的發(fā)布和訂閱。一個微服務可以是消息的發(fā)布者,把消息通過異步的方式發(fā)送到隊列或者訂閱主題下。作為消費者的微服務可以從隊列或者主題共獲取消息。通過消息中間件把服務之間的直接調用解耦。

如何快速搭建一個微服務架構
上圖:異步通信方式

通常異步的生產(chǎn)者/消費者模式,通過AMQP, STOMP, MQTT 等異步消息通訊協(xié)議規(guī)范。

數(shù)據(jù)的去中心化

單體架構中,不同功能的服務模塊都把數(shù)據(jù)存儲在某個中心數(shù)據(jù)庫中。

每個微服務有自己私有的數(shù)據(jù)庫,其它微服務不能直接訪問。單體架構,用一個數(shù)據(jù)庫存儲所有數(shù)據(jù)

微服務方式,多個服務之間的設計相互獨立,數(shù)據(jù)也應該相互獨立(比如,某個微服務的數(shù)據(jù)庫結構定義方式改變,可能會中斷其它服務)。因此,每個微服務都應該有自己的數(shù)據(jù)庫。

每個微服務有自己私有的數(shù)據(jù)庫,其它微服務不能直接訪問。每個微服務有自己私有的數(shù)據(jù)庫,其它微服務不能直接訪問。

數(shù)據(jù)去中心話的核心要點:

每個微服務有自己私有的數(shù)據(jù)庫持久化業(yè)務數(shù)據(jù)

每個微服務只能訪問自己的數(shù)據(jù)庫,而不能訪問其它服務的數(shù)據(jù)庫

某些業(yè)務場景下,需要在一個事務中更新多個數(shù)據(jù)庫。這種情況也不能直接訪問其它微服務的數(shù)據(jù)庫,而是通過對于微服務進行操作。

數(shù)據(jù)的去中心化,進一步降低了微服務之間的耦合度,不同服務可以采用不同的數(shù)據(jù)庫技術(SQL、NoSQL等)。在復雜的業(yè)務場景下,如果包含多個微服務,通常在客戶端或者中間層(網(wǎng)關)處理。

微服務架構的優(yōu)點:

每個服務都比較簡單,只關注于一個業(yè)務功能。

微服務架構方式是松耦合的,可以提供更高的靈活性。

微服務可通過最佳及最合適的不同的編程語言與工具進行開發(fā),能夠做到有的放矢地解決針對性問題。

每個微服務可由不同團隊獨立開發(fā),互不影響,加快推出市場的速度。

微服務架構是持續(xù)交付(CD)的巨大推動力,允許在頻繁發(fā)布不同服務的同時保持系統(tǒng)其他部分的可用性和穩(wěn)定性。

微服務架構的缺點:

微服務的一些想法在實踐上是好的,但當整體實現(xiàn)時也會呈現(xiàn)出其復雜性。

運維開銷及成本增加:整體應用可能只需部署至一小片應用服務區(qū)集群,而微服務架構可能變成需要構建/測試/部署/運行數(shù)十個獨立的服務,并可能需要支持多種語言和環(huán)境。這導致一個整體式系統(tǒng)如果由20個微服務組成,可能需要40~60個進程。

必須有堅實的DevOps開發(fā)運維一體化技能:開發(fā)人員需要熟知運維與投產(chǎn)環(huán)境,開發(fā)人員也需要掌握必要的數(shù)據(jù)存儲技術如NoSQL,具有較強DevOps技能的人員比較稀缺,會帶來招聘人才方面的挑戰(zhàn)。

隱式接口及接口匹配問題:把系統(tǒng)分為多個協(xié)作組件后會產(chǎn)生新的接口,這意味著簡單的交叉變化可能需要改變許多組件,并需協(xié)調一起發(fā)布。在實際環(huán)境中,一個新品發(fā)布可能被迫同時發(fā)布大量服務,由于集成點的大量增加,微服務架構會有更高的發(fā)布風險。

代碼重復:某些底層功能需要被多個服務所用,為了避免將“同步耦合引入到系統(tǒng)中”,有時需要向不同服務添加一些代碼,這就會導致代碼重復。

分布式系統(tǒng)的復雜性:作為一種分布式系統(tǒng),微服務引入了復雜性和其他若干問題,例如網(wǎng)絡延遲、容錯性、消息序列化、不可靠的網(wǎng)絡、異步機制、版本化、差異化的工作負載等,開發(fā)人員需要考慮以上的分布式系統(tǒng)問題。

異步機制:微服務往往使用異步編程、消息與并行機制,如果應用存在跨微服務的事務性處理,事務的實現(xiàn)更具挑戰(zhàn)性,其實現(xiàn)機制會變得復雜化。

可測性的挑戰(zhàn):在動態(tài)環(huán)境下服務間的交互會產(chǎn)生非常微妙的行為,難以可視化及全面測試。經(jīng)典微服務往往不太重視測試,更多的是通過監(jiān)控發(fā)現(xiàn)生產(chǎn)環(huán)境的異常,進而快速回滾或采取其他必要的行動。但對于特別在意風險規(guī)避監(jiān)管或投產(chǎn)環(huán)境錯誤會產(chǎn)生顯著影響的場景下需要特別注意。

關于微服務架構的取舍

在合適的項目,合適的團隊,采用微服務架構收益會大于成本。

微服務架構有很多吸引人的地方,但在擁抱微服務之前,也需要認清它所帶來的挑戰(zhàn)。

需要避免為了“微服務”而“微服務”。

微服務架構引入策略 – 對傳統(tǒng)企業(yè)而言,開始時可以考慮引入部分合適的微服務架構原則對已有系統(tǒng)進行改造或新建微服務應用,逐步探索及積累微服務架構經(jīng)驗,而非全盤實施微服務架構。

文章版權歸作者所有,未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/77662.html

相關文章

  • 中國人壽如何基于容器搭建金融PaaS云平臺

    摘要:具體技術細節(jié)的補充中國人壽兩朵云的最底層的容器調度與管理都是使用了平臺。決定采納容器擁抱,對整個中國人壽而言都是一次重大的變革。對中國人壽這樣的傳統(tǒng)金融企業(yè)而言,上一個并不容易。 6月28日,Rancher Labs在北京舉辦了Container Day 2018容器技術大會。在大會上,Rancher Labs CEO及聯(lián)合創(chuàng)始人梁勝博士、中國人壽研發(fā)中心開發(fā)五部副總經(jīng)理王川、技術處高...

    flybywind 評論0 收藏0
  • 【推薦】最新200篇:技術文章整理

    摘要:作為面試官,我是如何甄別應聘者的包裝程度語言和等其他語言的對比分析和主從復制的原理詳解和持久化的原理是什么面試中經(jīng)常被問到的持久化與恢復實現(xiàn)故障恢復自動化詳解哨兵技術查漏補缺最易錯過的技術要點大掃盲意外宕機不難解決,但你真的懂數(shù)據(jù)恢復嗎每秒 作為面試官,我是如何甄別應聘者的包裝程度Go語言和Java、python等其他語言的對比分析 Redis和MySQL Redis:主從復制的原理詳...

    BicycleWarrior 評論0 收藏0
  • 【推薦】最新200篇:技術文章整理

    摘要:作為面試官,我是如何甄別應聘者的包裝程度語言和等其他語言的對比分析和主從復制的原理詳解和持久化的原理是什么面試中經(jīng)常被問到的持久化與恢復實現(xiàn)故障恢復自動化詳解哨兵技術查漏補缺最易錯過的技術要點大掃盲意外宕機不難解決,但你真的懂數(shù)據(jù)恢復嗎每秒 作為面試官,我是如何甄別應聘者的包裝程度Go語言和Java、python等其他語言的對比分析 Redis和MySQL Redis:主從復制的原理詳...

    tommego 評論0 收藏0
  • 拷問傳統(tǒng)企業(yè)CIO:服務化值得嗎?

    摘要:以推出輕舟微服務平臺的網(wǎng)易云為代表,云計算公司正在微服務領域發(fā)力,促進企業(yè)數(shù)字化創(chuàng)新。以網(wǎng)易云輕舟微服務平臺為例,該平臺已經(jīng)在物流工業(yè)和金融等領域得到了深度應用。 所謂數(shù)字化轉型升級,就是以數(shù)字技術優(yōu)化傳統(tǒng)資源,企業(yè)需要謹慎地選擇合適的技術逐步完成自己的數(shù)字化戰(zhàn)略。以推出輕舟微服務平臺的網(wǎng)易云為代表,云計算公司正在微服務領域發(fā)力,促進企業(yè)數(shù)字化創(chuàng)新。那么,微服務對數(shù)字化轉型意味著什么?...

    bovenson 評論0 收藏0

發(fā)表評論

0條評論

最新活動
閱讀需要支付1元查看
<