上週，我談到了作爲一系列微服務開發的產品技術架構。談話幾分鐘後，很明顯團隊已經支付了微服務高級版，但沒有明顯的投資回報。這組微服務是由一個由10名工程師組成的團隊構建的，所有服務都是用java實現的，並使用消息總線將必要的數據複製到共享postgres實例中的自己的模式中。雖然工程師可能最有意願建立一個可以擴展的系統，但它立刻讓我想起了Donald Knuth的名言，
過早優化是萬惡之源
我認爲團隊會更有效率，如果系統被構建爲具有良好模塊性和服務之間鬆散耦合的整體系統，那麼系統就不那麼複雜了。
讓我們看一下微服務架構的優缺點，從我自己的經驗來看，我在SAP時爲我們構建的產品採用了微服務架構。
釋放靈活性
採用微服務使我們能夠靈活地根據微服務中代碼的成熟度和質量來決定哪些功能可以通過v1發佈。另一方面，單片應用程序意味着延遲發佈，直到我們把所有事情都弄好。
主題移交
雖然我不是世界各地分佈式團隊的忠實粉絲，但我們需要接受並繼續前進，這是今天的商業現實。通過遍佈三大洲（美國，德國和印度）的全球開發團隊實施產品非常具有挑戰性，但在微服務方面明確分離功能使我們能夠靈活地在不同地點之間移動功能。由於團隊不需要了解整個代碼庫以詳細瞭解功能集的一小部分，因此主題切換非常易於管理。
規模
擴展單片應用程序（尤其是水平擴展）絕對是可能的，但並非應用程序的所有部分都可能從擴展中受益，因爲吞吐量要求因產品的不同功能而異。微服務架構允許我們根據吞吐量要求擴展應用程序的不同部分，並有效利用可用資源。
自治
我非常相信團隊的完全自主權，這與微服務架構相得益彰，因爲團隊之間的依賴關係減少到最小，並且通過定義良好的接口或API進行通信。團隊完全自治的缺點是編程語言，框架，開發工具的動物園，一旦團隊擴展到100人，就變得無法管理。雖然微服務架構鼓勵多語言運行時，但我建議堅持幾個運行時，幾個框架以及一個基於一個工具集的構建和發佈過程。
監測和支持
由於微服務按照定義分佈在許多服務器（物理或虛擬）上以實現水平擴展，因此它們運行的平臺應提供強大的監控和支持基礎架構。監視和支持在調試和查找日誌文件中的錯誤的根本原因方面由於缺少聚合每個產品的日誌和跟蹤文件的工具而變得非常麻煩。例如，支持工程師可能需要查看每個微服務的大量日誌文件，以找出錯誤的根本原因。
構建和發佈
在微服務部署的情況下，構建和發佈過程的複雜性有時會使團隊士氣高漲，因爲他們不斷與構建作業和部署作業作鬥爭。對我們來說，缺乏構建，部署和發佈自動化是一項挑戰。照顧一個構建工作，一個代碼掃描，每個服務就像放牧貓一樣。如果有什麼東西打破沒有人通知。事實上，我們每個微服務都有多個構建作業 - 一個用於拉取請求，一個用於運行代碼掃描和集成測試的主構建，另外一個可以發佈到工件庫中。完全自動化的構建和發佈過程是微服務架構有效提高開發人員工作效率的關鍵。
安全
在微服務架構中獲得安全性是一個真正的複雜性助推器。我們花了很多時間來確定基本的安全要求，例如身份驗證和授權（特別是在服務到服務通信上下文中），因爲每個微服務都運行在它自己的進程中，而不是整體結構。使用單一應用程序，處理安全性就像將spring安全庫放入Web應用程序，創建spring-security.xml並向REST端點添加一些安全註釋一樣簡單。使用微服務，使用JWT處理複雜的OAuth流並在服務之間傳遞令牌並非易事.
數據複製
最後，我認爲在微服務方面最重要的權衡是關於是否複製數據的爭論（特別是在大數據環境中）。關於如何複製數據的技術 - 消息總線，點對點REST API等是這個決定的簡單後續。
通常，爲微服務（有界上下文）獲取服務邊界非常困難。如果服務邊界不正確，則會導致數據重複並增加服務之間的耦合。數據重複是一個很大的問題，特別是當微生物主要是分析性的並且需要依賴於或多或少相同的大數據集進行分析時。
在大數據分析環境中，我不是複合服務或複合API的忠實粉絲（我將其定義爲需要處理大約數百萬個數據點以滿足請求 - 如排序，過濾）。複合REST API實現往往性能較慢，無法與DB的響應時間相匹配，DB是處理連接，聚合，過濾等事情的理想場所。
我們最終創建了一個數據服務，它創建了一個像依賴的平臺，因爲幾乎所有其他微服務都依賴於這個服務來查詢大數據集。必須在此層中實現任何新查詢，這會降低新功能的開發速度。但查詢響應時間對於應用程序來說至關重要，因此我們可以進行權衡。
生存還是毀滅 ！
與所有軟件架構一樣，爲您的產品採用或不使用微服務是一種權衡討論和決策。