欧美vvv,亚洲第一成人在线,亚洲成人欧美日韩在线观看,日本猛少妇猛色XXXXX猛叫

擊上方 "程序員小樂"關注, 星標或置頂一起成長

每天凌晨00點00分, 第一時間與你相約

每日英文

Life is short, so smile while you still have teeth.

人生太短，所以笑吧，乘你現在還有牙齒時。

每日掏心話

生命就好像旅行，在過程中我們可以擁有一些東西，但終究不能帶走它。

來自：颯然Hang | 責編：樂樂

鏈接：rowkey.me/blog/2018/06/02/microservice-pitfall/

程序員小樂(ID:study_tech)第 877 次推文 圖源：百度

往日回顧：Java 中 volatile 關鍵字的最全總結，趕快給自己查缺補漏吧！

正文

O’Reilly的電子書《Microservices AntiPatterns and Pitfalls》講述了在微服務設計實現時十種最常見的反模式和陷阱。本文基于此書，將這十個點列出。
關于微服務：1、微服務的生離死別，看這篇就對了！
2、一文詳解微服務架構
3、我只是下了個訂單，鬼知道我在微服務里經歷了什么？
4、微服務之間的最佳調用方式
數據驅動遷移反模式（Data-Driven Migration）

如上圖所示，此種反模式的問題在于微服務的粒度沒有最終確定之前就做了數據遷移，如此當不斷的調整服務粒度時，那么數據庫就免不了頻繁遷移，帶來極大的成本。更好的方式如下圖所示：

即先分離功能，數據庫先保持之前的單體，等到服務粒度最終確定之后，再分離數據庫。

超時反模式（The Timeout）微服務架構是由一系列分離的服務組成的，這些服務之間通過一些遠程協議進行互相之間的通信。其中牽扯到了服務的可用性和響應性問題。如下圖所示：

• 可用性：服務消費方能夠連接服務方，并可以向其發送請求。

• 響應性：服務方能夠在消費方期望時間內給予請求響應。




• 為了防止服務的不可用和無法響應，通常的做法就是設置一個調用超時。此種做法表面上看是沒問題的，但是試想一下如下情景：發起一個購買100個商品的請求，請求成功返回一個確認號。如果當請求超時但是請求在服務端已經成功執行了，此時這個交易實際是完成的，但是消費方沒有拿到確認號，如果重試請求，那么服務方需要一個復雜的機制判斷這是否一次重復提交。




• 一種解決此問題的方案是設置一個較長的超時時間，如一個服務的通常響應耗時需要2s，最大耗時需要5s，那么超時時間可以設置為10s。但這樣的問題就是如果服務不可用，所有消費方都得等待10s，這個是非常損耗性能的。




• 解決超時反模式的方案就是使用“斷路器模式”。就類似于房屋中的電源斷路器，當斷路器關閉，電流可以通過，當斷路器打開，那么電流中斷一直到斷路器關閉。斷路器模式就是說當檢測到服務方無法響應時就打開，后續的請求都會被拒絕掉。一旦服務方可響應了，那么斷路器關閉，恢復請求。其工作模式如下圖所示：






• 斷路器會持續地監測遠程服務，確保其是可響應的。只要服務可響應，那么斷路器會一直關閉，允許請求通過。如果服務突然不可響應，那么斷路器打開，拒絕后續的請求。而后續如果斷路器又檢測到服務恢復了，那么斷路器會自動關閉，請求也就恢復了。此種方案與超時時間相比，最大的優勢就是一旦服務不可響應，那么斷路器模式可以讓請求立刻返回而不是需要等待一定的時間。




• Hystrix的Netflix是此種斷路器模式的一種開源實現。此外，Akka中也包含了一個斷路器實現：Akka CircuitBreaker類。




• 關于“斷路器模式”的詳細信息可見：https://martinfowler.com/bliki/CircuitBreaker.html。關注微信公眾號：互聯網架構師，在后臺回復：2T，可以獲取全套架構師視頻教程，都是干貨。





• 共享反模式（“I Was Taught to Share”）微服務被普遍認為是一種不共享任何東西的架構。但實際上只能是盡可能地少共享，畢竟在某些層面代碼被多個服務共享也能帶來一定好處。




• 例如，與單獨部署一套安全服務（認證和授權）其他所有服務都通過遠程訪問此服務相比，把安全相關的功能封裝成jar包（security.jar），然后其他服務都集成此jar包，就能夠避免每次都要發起對安全服務的訪問，從而提高性能和可靠性。但后面的方案帶來的問題就是依賴噩夢：每一個服務都依賴多個自定義的jar包。如此不僅打破了服務之間的邊界上下文，同時也引入了諸如總體可靠性、變更控制、易測試性、部署等問題。




• 在一個使用面向對象編程語言的單體應用中，使用abstract類和接口實現代碼復用和共享是一個良好的實踐。但當從單體切換到微服務架構時，對于很多自定義的共享類和工具類（日期、字符串、計算）的處理要考慮到微服務間共享的東西越少越有利于保持服務間的邊界上下文，從而更利于快速測試和部署。以下是幾種推薦的方式，也是解決“共享反模式”的方案：




• 共享項目







• 將共享的代碼作為一個項目在編譯期與各個服務集成。此種方式便于變更和開發軟件，但是最大的問題在于很難發覺哪一個共享模塊被修改以及修改的原因，也無法確定自己的服務是否需要這些變更。尤其是在服務發布前期發現某一個共享模塊發生了變動的話需要再一次的測試才能走后續流程。




• 共享庫






• 此種方式即將共享的代碼作為類庫集成到服務中。如此每次共享的庫有改動，服務都需要重新打包、測試、重啟。但相比起第一種，其有版本標記，能夠更好地控制服務的部署和開發，服務開發者可以自己控制何時將共享庫的改動集成進來。




• 更進一步的，如果采用此種方案，一定要避免把所有共享的代碼都打包進一個jar包中如common.jar。否則會很難確定何時要把庫的變動集成到服務中。更好的做法是將共享代碼分成幾個單獨上下文的庫，如：security.jar、dateutils.jar、persistence.jar等，如此會比較容易的確定何時去集成共享庫的變動。




• 冗余






• 此種方案違反DRY原則，在每一服務中都冗余一份共享代碼，能夠避免依賴共享也能夠保持邊界上下文。但是一旦共享的代碼有變動，那么所有服務都需要改動。因此，此種方案適用于共享模塊非常穩定，極小可能變動的情況。




• 服務合并







• 當多個服務共享的代碼變動比較頻繁時可以采用此種方案合并成一個服務，如此就避免了多了服務頻繁的測試和部署，也避免了依賴共享庫。




• 可達性報告反模式（Reach-in Reporting）微服務中各個服務以及其相應的數據都是包含在一個單獨的邊界上下文中的，也就是說數據是隔離到多個數據庫中的。因此，這也會使得收集微服務的各種數據生成報告變得相對困難。一般來說有四種方案解決這個問題。其中，前三種都是從各個微服務中拉取數據，是這里所說的反模式，被稱作“Reach-in Reporting”。




• 數據庫拉取模式






• 報告服務直接從各個服務的數據庫中拉取數據從而生成各種報告。此種方式簡單迅速，但是會讓報告服務和業務服務相互依賴，是一種數據庫共享集成風格（通過共享的數據庫將多個應用耦合在一起）。如此一旦數據庫有改動，所有相關服務都要改動，也就打破了微服務中極為重要的邊界上下文。




• HTTP拉取模式






• 與數據庫拉取模式相比，此種方式不再是直接去訪問服務的數據庫，而是通過HTTP接口去請求服務的數據。此種方式能夠保持服務的邊界上下文，但是性能比較慢，而且HTTP請求無法很好的承載大數據。




• 批量拉取模式






• 此種方式會有一個單獨的報告數據庫/數據倉庫來存儲各個服務的聚合數據。會通過一個批量任務（離線或者基于增量實時）將服務更新的數據導入到報告數據庫/數據倉庫中。與數據庫拉取模式一樣，此種方式這也是一種數據庫共享集成風格，會打破服務的邊界上下文。




• 異步事件推送模式






• 此種方式即解決“Reach-in Reporting”反模式的方案。每個服務都把自己的發生的事件異步推送到一個數據捕獲服務，后續數據捕獲服務會將數據解析存儲到報告數據庫中。此種方式實現起來較復雜，需要在服務和數據捕獲服務之間制定一種協議用于異步傳輸事件數據。但其能夠保持服務的邊界上下文，同時也能保證數據的時效性。




• 沙粒陷阱（Grains of Sand）微服務實現中最有挑戰的問題在于如何拆分service，如何控制服務的粒度，而正確的服務粒度則決定了微服務是否能夠成功實現。服務粒度也能夠影響到性能、健壯性、可靠性、易測試性、部署等。




• “沙粒陷阱”即把服務拆分的太細。其中的一個原因就是很多時候開發者會把一個class與一個服務等同。合理的，應該是一個服務組件（Service component）對應一個服務。一個服務組件具有清晰、簡潔的角色、職責，具有一組定義好的操作。其一般通過多個模塊（Java Class）實現。如果組件和模塊是一對一的關系，那么不僅僅會造成服務粒度過細同時也是一種不好的編程實踐：服務的實現都是通過一個Class，那么此Class會非常大并且承擔太多的責任，不利于測試和維護。




• 更進一步的，服務的粒度并不應該受其中實現類的數目影響：有些服務可能只需要一個類就可以實現，而有些服務會需要多個類來實現。




• 為了避免“沙粒陷阱”，可以通過以下三種測試來判斷服務粒度是否合理：




• 分析服務范圍和功能




• 要明確服務用來干什么？有哪些操作？一般通過使用文檔或者語言來描述服務的范圍和功能就能夠看出來服務是否做的工作太多。如果在描述中使用了“和”（“and”）或者“此外”（“in addition”）之類的詞，很有可能就是此服務職責太多。




• 服務的高內聚是一種良好的實踐，其明確一個服務提供的操作之間必須要是有關聯的。如對于一個顧客服務，有以下操作：




• 添加顧客

• 更新顧客信息

• 獲取顧客信息

• 通知顧客

• 記錄顧客評論

• 獲取顧客評論




• 其中的前三個操作都是對顧客的CRUD操作，是相關聯的。而后三者則無關。為了實現服務的高內聚，合理的應該是把此服務拆分成三個服務：顧客維護、顧客通知、顧客評論。




• 如此，以粗粒度的服務開始，然后逐漸拆分成細粒度的服務有利于對微服務的拆分。




• 分析數據庫事務




• 傳統的關系型數據庫都提供了ACID事務特性用于把多個更新操作打包成一個整體提交，要么都成功，要么都失敗。而在微服務中，由于服務都是一個個分離的應用，很難實現ACID，一般實現BASE事務（basic availability、soft state、eventual consistence）即可。但是無法避免的，仍然會有一些場景是需要ACID的。因此，當你不斷的需要在BASE和ACID事務做判斷和取舍的時候，很有可能就是服務粒度過細。




• 如果業務場景無法接受最終一致性，那么最好就是將服務粒度粗化一些，把多個更新操作放到一個服務中。




• 分析服務編排




• 這里主要說的是服務之間的互相通信。由于對服務的調用都是一次遠程調用，因此服務編排會非常大的影響微應用總體的性能。此外，它也會影響系統整體的健壯性和可靠性，越多的遠程調用，那么越高的幾率會有失敗或者超時的請求出現。




• 如果發現完成一次業務邏輯需要調用太多的遠程服務，就說明服務的粒度可能太細了。這時候就需要將服務粗化。而合并細粒度服務還能夠提高性能，提升總體的健壯性和可靠性。同時也減少了多個服務間的依賴，更利于測試和部署。




• 此外，使用響應式編程技術異步并行調用遠程服務也是一種提升性能和可靠性的方案。




• 無因的開發者陷阱（Developer Without a Cause）此陷阱主要講的是開發者或者架構師在做設計時很多時候是拍腦袋在做，沒有任何合理的原因或者原因是錯誤的，也不會做取舍。而想要解決此問題，不僅僅是架構師，開發者也需要同時了解技術帶來的好處以及缺陷，從中做權衡。




• 了解業務驅動是避免此陷阱的關鍵一步。每一個開發者和架構師都應該清楚的了解下面這些問題的答案：




• 為什么要使用微服務？

• 最重要的業務驅動是什么？

• 架構中的哪一點是最為重要的？




• 假如易部署性、性能、健壯性、可擴展性是系統最看重的特性，那么對于不同的業務側重點，微服務的粒度需求也是不同的。細粒度的服務能夠達到更好的易測試性和易部署性，而粗粒度的服務則有更好的性能、健壯性以及可靠性。




• 追隨流行陷阱（Jump on the Bandwagon）

• 微服務是目前非常流行的架構理念，越來越多的公司也都在緊跟這個潮流紛紛轉型微服務架構，而不管到底自己是否真的需要。為了避免此陷阱，需要首先了解微服務的優點和缺點。




• 優點：




• 易部署：容易部署是微服務的一個很大的優點。畢竟相比起一個龐大的單體應用，一個小并且職責單一的微服務的部署非常簡單并且帶來的風險也會小很多。而持續部署技術則進一步放大了這個優點。

  
  

• 易測試：職責單一、共享依賴少使得測試一個微服務是很容易的。而基于微服務做回歸測試與單體大應用相比也是很容易的。 控制變更：每個服務的范圍和邊界上下文使得很容易控制服務的功能變動。

  
  

• 模塊化：微服務就是一個高度模塊化的架構風格。這種風格也是一種敏捷方式的表達，能夠很快的響應變化。一個系統模塊化程度越高，就越容易測試、部署和發布變更。一個服務粒度劃分合理的微服務系統是所有架構中模塊化程度最高的架構形式。

  
  

• 可擴展性：由于每一個服務都是一個職責單一的細粒度服務，因此此種架構風格是所有架構分隔中可擴展性最高的。其非常容易擴展某一個或者某幾個功能從而滿足整體系統的需求。而得益于服務的容器化特性以及各種運維監控工具，服務也能夠自動化進行啟動和關閉。




• 缺點：




• 組織變動：微服務需要組織在很多層面進行變動。研發團隊需要包含UI、后端開發、規則處理、數據庫處理建模等多種職位，從而使得一個小的團隊能夠具有實現微服務的所有技術棧。同時，傳統的單體、分層應用架構的軟件發布流程也需要更新為自動化、高效的部署流水線。

  
  

• 性能：由于服務都是隔離的，因此發起對服務的遠程調用肯定是會影響性能的。服務編排、運行環境都是影響性能的很大因素。了解遠程調用的延遲、需要與多少服務通信都是與性能相關的需要掌握的信息。

  
  

• 可靠性：和性能一樣。服務的遠程調用越多，那么失敗的幾率就越高，總體的可靠性就會越低。

  
  

• DevOps：隨著微服務架構而來的是成千上百的服務。手動管理這么多的服務是很不現實的。這就對于自動化運維部署、協作提出了很高的挑戰。需要依賴非常多的操作工具和實踐，是一個非常復雜的工作。目前差不多有12種類型的操作工具（監控工具、服務注冊、發現工具、部署工具等）和框架在微服務架構中被使用，其中每一種又包含了很多具體的工具和產品供選擇。對于這些工具和框架的選擇一般都會需要將近數月的研究、測試、權衡分析才能做出最適合的技術選型。




• 了解了微服務的優缺點后，下一步則需要根據實際的業務來分析微服務是不是解決這些問題的最佳方案。可以采取以下問題：




• 業務和技術的目標是什么？

• 使用微服務是為了完成什么？

• 目前和可預知的痛點是什么？

• 應用的最關鍵的技術特性是什么？（性能、易部署性、易測試性、可擴展性）




• 回答這些問題再結合微服務的優缺點能夠讓你明確現在是否是使用微服務的適當時機。




• 除了微服務以外，還有其他7種比較普遍使用的架構供選擇：




• 基于服務的架構（Service-Based）

• 面向服務的架構（Service-Oriented）

• 分層架構（Layered）

• 微內核架構（Microkernel）

• 基于空間的架構（Space-Based）

• 事件驅動架構（Event-Driven）

• 流水線架構（Pipeline）




• 靜態合約陷阱（The Static Contract）微服務的消費方和服務提供方之間會有一個合約/協議用來規定輸入輸出數據的格式、操作名稱等等。一般情況下這個合約是不變的。但是如果沒有使用版本號來管理服務接口，那么就會進入“靜態合約”陷阱。




• 給合約打上版本標記不僅僅能夠避免巨大的變動（服務提供方修改合約使得所有消費方也都得修改），還能夠提供向后兼容性。這里有兩種技術可以實現合約的版本號：




• 在頭部信息附加版本號






• 如圖，此種方式即在遠程訪問協議的頭部添加版本信息。而如果遠程協議使用的是REST，那么還可以使用vendor mime type（vnd）來指定合約的版本號。如下：

POST /trade/buy
Accept: application/vnd.svc.trade.v2+json

服務接受到請求，能夠通過正則等手段簡單解析出其中的合約版本號再根據版本號做相應的處理。
如果使用消息隊列，那么可以將版本號放置在屬性部分(Property section)。JMS的一個例子如下：

String msg=createJSON("acct","12345","sedol","2046251","shares","1000");
jsmContext.createProducer()
.setProperty("version",2)
.send(queue,msg);

在合約本身中附加版本號

此種方式版本號獨立于遠程訪問協議，與頭部信息版本號相比，這也是其最大的優點。但與此同時，其缺點比較多。首先要從請求信息主體中解析版本號，會出現很多解析的問題。其次，合約的模式可能會非常復雜，使得很難做數據轉換。最后，服務還要引入對模式的驗證邏輯。
我們到了嗎陷阱（Are We There Yet）微服務架構中，各個服務都是獨立的個體，也就意味著所有客戶端或者API層和服務之間的通信都是一次遠程調用。如果對這些遠程調用的耗時沒有什么概念，那么就陷入了“Are We There Yet”陷阱。合理的做法需要去測試遠程訪問的平均延遲、長尾延遲（95%、99%、99.%之外的請求延遲）等指標。而很多時候即使有很好的平均延遲，但是較差的長尾延遲會造成非常大的破壞。
在生產環境或者準生產環境測試有助于去了解應用的真實性能。例如，一個業務請求需要調用四個服務，假設一個服務調用的延遲是100毫秒，那么加上業務請求本身的延遲，完成此次業務請求共需要500毫秒的延遲。這和單單從代碼上去看得出的結論是不一樣的。
了解目前所用協議的平均延遲是一方面，另一方面則需要對比其他遠程協議的延遲，從而在合適的地方使用合適的協議。如：JMS、AMQP、MSMQ。

如圖，AMQP協議的性能是最好的。那么結合業務場景，就可以選擇REST作為客戶端與服務間的通信協議，AMQP做為服務之間的通信協議以提高應用的性能。
當然，性能并非在選擇遠程協議時唯一考慮的因素。下一節中就會考慮利用消息隊列的一些額外功能。
REST使用陷阱（Give It a Rest）REST現在是微服務中用的最多的通信協議。流行的開發框架如DropWizard、Spring Boot都提供了REST支持。但是如果只選擇REST這一種協議，不去考慮其他諸如消息隊列的優勢，那么就陷入了“REST使用”陷阱。畢竟異步通信、廣播、合并請求事務這些需求，REST是很難實現的。
消息隊列標準目前包括平臺特定和平臺無關兩種。前者包括Java平臺中的JMS和C#平臺的MSMQ，后者則是AMQP。對于平臺特定的消息標準JMS，其規范了API，因此切換broker實現（ActiveMQ、HornetQ）時無需修改API，但由于底層通信協議是不同的，集成的客戶端或者服務端jar包需要隨著修改。
對于平臺無關的消息標準，其規范了協議實現標準，并沒有規范API。使得不同平臺之間都可以互相通信，而不管實際產品是什么。如一個使用了RabbitMQ的客戶端可以很容易地與一個StormMQ通信（假設使用的協議相同）。也就是其獨立于平臺的特性使得RabbitMQ成為微服務架構中最流行的消息隊列。
異步請求
異步通信是消息隊列適用的場景之一。服務消費者發起請求后無需等待服務方響應能夠提高總體的性能，同時調用方無需擔心調用超時，也就無需使用斷路器，從而提高了系統的可靠性。
廣播
將消息廣播給多個service是消息隊列的又一個適用場景。一個消息生產者向多個消息接受者發送消息，無需知道誰在接受消息以及如何處理它。
事務請求
消息系統提供了對事務消息的支持：如果多個消息被發送到了在一個交易上下文的多個隊列或者主題中時，那么直到消息發送者commit，服務才會真正的接受到相應的所有消息（在commit之前會一直保存在隊列中）。

因此對于服務消費者需要合并多個遠程請求到一個事務中的場景可以選擇事務消息。

歡迎在留言區留下你的觀點，一起討論提高。如果今天的文章讓你有新的啟發，學習能力的提升上有新的認識，歡迎轉發分享給更多人。

猜你還想看

阿里、騰訊、百度、華為、京東最新面試題匯集

負載均衡 (Load balancing) 在分布式架構中是怎么玩起來的？

重磅！有贊前技術負責人被刑拘！走私毒品判了3年！

如果網站的 Cookie 特別多特別大，會發生什么情況？

關注訂閱號「程序員小樂」，收看更多精彩內容
嘿，你在看嗎？