原文：微服務架構比原有系統要複雜得多，由於團隊必須要管理與支援許多移動的部件，整體環境愈加複雜。其中一些必須要考慮的問題包括：
其他要考慮的事情包括：
運營與基礎架構：開發團隊必須與運營團隊更加緊密地合作，否則由於多個運營同時進行，情況會失去控制。
支援：對微服務安裝提供支援和維護，比之前為單一整體式應用提供支援維護要困難得多。微服務的每個部件都可能涉及了多種框架及語言，在提供支援時，近乎無限的複雜度會影響相關人員新增服務的決策。如果某個團隊成員希望建立乙個使用深奧語言的新服務，很可能會影響到整個團隊，因為大家必須確保這個新服務能夠與現有的部分協作。
監控：在新增新服務時，維護與配置監控的能力也會是乙個挑戰，必須依賴自動化來確保監控跟得上服務規模的變化速度。
應用安全：架構中服務的發展為黑客、解密高手與犯罪分子製造了更多侵犯的目標。要跟蹤各種運營系統、框架與語言會導致負責安全的團隊將全部精力放在確保系統不易受到攻擊方面上。
請求：在服務間傳送資料的方式之一就是使用request header，它可以包含類似身份驗證這樣的細節，從而減少了所需的請求數量。但當這類資料傳送大批量進行時，就會增加對各個團隊合作的需求。
快取：快取有助於減少所需的請求數量，涉及多個服務的請求在快取後會迅速變得複雜起來，需要不同服務及其開發團隊進行溝通。
容錯性：微服務的口號就是「互相依賴」。各項服務必須能經受得住直接的失敗與無法解釋的超時問題。故障可能會產生多公尺諾效應，通過某些服務產生級聯效應，並可能會讓某些服務失效。在這種環境下，容錯也比在單一整體式系統中要複雜得多。
在舊式開發環境中，it部門中負責不同功能的部門合作很少，隨著運營、開發與質量保證（qa）團隊合作形式的發展，以及貫通整個軟體開發流程的溝通加強，最終出現了devops。devops並不是由某個人或單個小組所擔任的角色，它實際上是將有助於運營與開發密切合作的架構進行了概念抽象。在微服務架構中，開發者負責建立系統，以成功交付最終的產品。
隨著大型及小型公司逐漸向微服務平台遷移，開發者也必須隨之發展。由於部署微服務非常簡單，開發者會逐漸參與到**部署與產品監控的工作中。這種方式與傳統案例產生了對比：在過去開發者負責編寫**，將其交付給另一支團隊（devops）來執行部署與維護；而現在開發者與devops逐漸融合成更小的應用團隊，主要負責三項工作：應用的構建、部署與監控。
微服務正在改變團隊的組成方式，讓公司得以圍繞著特定的服務來建立團隊，並賦予它們自治權以及一定範圍內的責任。這種方式可以讓公司根據瞬息萬變的業務需求而快速作出調整，且不會影響到核心業務，同時也方便新人快速融入團隊。
開發者可能要應對的其他挑戰包括：
一旦轉變過程開啟，你就會發現之前預想不到的新挑戰出現，包括：
採用微服務時必須解決的四個挑戰
原文 微服務架構比原有系統要複雜得多，由於團隊必須要管理與支援許多移動的部件，整體環境愈加複雜。其中一些必須要考慮的問題包括 其他要考慮的事情包括 運營與基礎架構 開發團隊必須與運營團隊更加緊密地合作，否則由於多個運營同時進行，情況會失去控制。支援 對微服務安裝提供支援和維護，比之前為單一整體式應用...
微服務的四大挑戰
微服務作為一種軟體價值快速開發和交付的手段，有很明顯的上公升勢頭。容器技術已經從邊緣技術飛速的變成主流，企業組織也都爭先恐後的加入了微服務的行列。然而，在你衝出來擁抱微服務之前，有幾件事情需要你記住。首先讓我們來談談什麼是微服務，甚至在海量的相對較新的術語當中，它仍是乙個相對較新的術語。ai hil...
確保微服務應用安全的四個最佳實踐
在生產環境中採用與部署微服務應用的決策上，很顯然安全性佔據了非常重要的角色。根據451 research的研究報告 2016年軟體定義基礎架構前景展望 在未來一年中，將近45 的企業或已實現，或計畫推出基於容器的應用。隨著在企業與容器應用方面devops實踐逐漸普遍起來，安全管理者需要掌握維護應用安...