采用微服務時必須解決的四個挑戰

原文： 4 Challenges You Need to Address with Microservices Adoption

作者： Saba Anees，AppDynamics公司的內容運營專員

翻譯： 孫薇

在過去幾周，我們介紹了微服務的概念，以及 它在商業計劃中的角色 ，還有 企業遷移到微服務模型的方式 ——遷移到微服務的工作對企業提出了很大的挑戰。在本周的文章中，我們將會對遷移到微服務時可能遇到的障礙，以及付出的努力最終所帶來的好處進行深入探究。

微服務架構

微服務架構比原有系統要復雜得多，由于團隊必須要管理與支持許多移動的部件，整體環境愈加復雜。其中一些必須要考慮的問題包括：

• 在添加更多的微服務時，必須確保這些微服務能夠一起擴展。顆粒度更細致，代表著可移動的部件更多，從而導致系統更加復雜。
• 參與交互的服務越多，可能的故障點就越多。聰明的開發者總會未雨綢繆，為解決故障制定好計劃。
• 將功能從單一整體化架構向微服務架構遷移時，會有很多持續通訊的小型組件產生，追蹤單個業務事務在不同層面中的性能問題可能非常困難，因此，我們可以通過調用各種相關方法，包括自定義header、token或ID來解決。
• 由于微服務是無狀態的、分布式的、獨立的，因此傳統的日志記錄方式不再實用——就算想要簡單地定位某個問題，都有可能制造出過多日志。微服務的日志必須能與跨平臺的事件相關聯。

其他要考慮的事情包括：

1.運營與基礎架構： 開發團隊必須與運營團隊更加緊密地合作，否則由于多個運營同時進行，情況會失去控制。

2.支持： 對微服務安裝提供支持和維護，比之前為單一整體式應用提供支持維護要困難得多。微服務的每個部件都可能涉及了多種框架及語言，在提供支持時，近乎無限的復雜度會影響相關人員添加服務的決策。如果某個團隊成員希望創建一個使用深奧語言的新服務，很可能會影響到整個團隊，因為大家必須確保這個新服務能夠與現有的部分協作。

3.監控： 在添加新服務時，維護與配置監控的能力也會是一個挑戰，必須依賴自動化來確保監控跟得上服務規模的變化速度。

4.應用安全： 架構中服務的發展為黑客、解密高手與犯罪分子制造了更多侵犯的目標。要跟蹤各種運營系統、框架與語言會導致負責安全的團隊將全部精力放在確保系統不易受到攻擊方面上。

5.請求： 在服務間發送數據的方式之一就是使用request header，它可以包含類似身份驗證這樣的細節，從而減少了所需的請求數量。但當這類數據發送大批量進行時，就會增加對各個團隊合作的需求。

6.緩存： 緩存有助于減少所需的請求數量，涉及多個服務的請求在緩存后會迅速變得復雜起來，需要不同服務及其開發團隊進行溝通。

7.容錯性： 微服務的口號就是“互相依賴”。各項服務必須能經受得住直接的失敗與無法解釋的超時問題。故障可能會產生多米諾效應，通過某些服務產生級聯效應，并可能會讓某些服務失效。在這種環境下，容錯也比在單一整體式系統中要復雜得多。

關注DevOps

在舊式開發環境中， IT部門中負責不同功能的部門合作很少 ，隨著運營、開發與質量保證（QA）團隊合作形式的發展，以及貫通整個軟件開發流程的溝通加強，最終出現了DevOps。DevOps并不是由某個人或單個小組所擔任的角色，它實際上是將有助于運營與開發密切合作的架構進行了概念抽象。在微服務架構中，開發者負責創建系統，以成功交付最終的產品。

隨著大型及小型公司逐漸向微服務平臺遷移，開發者也必須隨之發展。由于部署微服務非常簡單，開發者會逐漸參與到代碼部署與產品監控的工作中。這種方式與傳統案例產生了對比：在過去開發者負責編寫代碼，將其交付給另一支團隊（DevOps）來執行部署與維護；而現在開發者與DevOps逐漸融合成更小的應用團隊，主要負責三項工作：應用的構建、部署與監控。

微服務正在改變團隊的組成方式，讓公司得以圍繞著特定的服務來創建團隊，并賦予它們自治權以及一定范圍內的責任。這種方式可以讓公司根據瞬息萬變的業務需求而快速作出調整，且不會影響到核心業務，同時也方便新人快速融入團隊。

開發者可能要應對的 其他挑戰 包括：

• 了解如何組合微服務架構的JavaScript開發者短缺；
• 理解及實現物聯網服務；
• 協助公司將科技引入商業計劃與策略上；
• 讓業務經理了解：怎樣應用開放API來加強現有產品線，并在市場上開拓新的機遇；
• 如何簡化開發堆棧，選擇正確的技術，并在供應商提供的中間件沒有價值時提出拒絕；
• 從Netflix等行業領導者那里學習經驗，并決定實現哪些微服務對公司最有好處；
• 了解這一點：很多供應商尚未建立起穩定的微服務平臺；
• 同一時間內管理及運營的個體微服務或達數百，要能應對這種壓力；
• 管理日益增長的復雜團隊網——由尚未完全了解微服務方法的運營者、架構師、開發者、QA團隊以及整合者所組成。

開始轉變

一旦轉變過程開啟，你就會發現之前預想不到的新挑戰出現，包括：

• 轉移到微服務上的工作負載應該有多少？
• 是否該允許代碼遷移到不同服務上？
• 在運營持續時，如何確定每個微服務的邊界？
• 如何監控微服務的性能？

想要了解更多信息，請 點擊這里 閱讀英文電子書全文《如何使用微服務構建與拓展》。

來自： http://www.iteye.com/news/31586