我是一個雲API開發人員和架構師，目前正在為美國的一個大型零售客戶開發基於谷歌GCP的微服務。
向微服務的轉換/實現為公司帶來了巨大的挑戰。基於我在生產中接觸到的微服務經驗，我闡述一下面臨的這些挑戰和解決方案。
我寫這篇文章是在2018年6月。此時，微服務體系結構還沒有成熟到能夠完全解決所有現有的挑戰，但是，開源社區和IT產品公司正試圖解決所有這些問題。所有關於這一主題的新研究都是基於找到應對新挑戰的解決方案。
這些是微服務體系結構和所提出的解決方案面臨的十大挑戰：
1、數據同步——我們使用異步消息傳遞平臺，通過有事件源體系結構來解決這個問題， 可使用saga設計模式可以解決這一挑戰。
2、安全性——API網關可以解決這些挑戰。Kong非常流行，並且是開源的，很多公司都在生產中使用它。還可以使用JWT令牌、Spring security和Netflix Zuul/ Zuul2為API安全開發定製解決方案。企業解決方案也可用，比如Apigee和Okta(兩步身份驗證)。Openshift主要用於公共雲安全，比如Red Hat Linux基於內核的安全性和基於名稱空間的應用程序到應用程序的安全性。
3、版本控制——這將由API註冊和發現API使用動態Swagger API處理，它可以動態更新並與服務器上的使用者共享。
4、服務發現——這將由像Kubernetes和OpenShift這樣的API發現工具來解決。它也可以在代碼級別使用Netflix Eureka完成。但是，在編排層中執行它會更好，並且可以通過這些工具進行管理，而不是通過代碼和配置來執行和維護它。
5、數據過時性——數據庫應該經常更新以提供最近的數據。API將從最近更新的數據庫中獲取數據。還可以在數據庫中的每個記錄中添加時間戳條目，以檢查和驗證最近的數據。可以使用緩存並根據業務需求定製可接受的驅逐策略。
6、調試和日誌記錄——有多種解決方案。通過將日誌消息推送到Kafka、谷歌PubSub等異步消息平臺，可以使用外部化的日誌記錄。客戶端可以在header中提供一個相關ID，以便在所有pods/Docker容器中跟蹤相關日誌。此外，可以使用IDE單獨在每個微服務上進行本地調試或檢查日誌。
7、測試——可以通過模擬REST api或集成/依賴api來解決這個問題，這些api不能用於使用WireMock、BDD、Cucumber、集成測試、使用JMeter進行性能測試，以及任何好的分析工具，如Jprofiler、DynaTrace、YourToolKit、VisualVM等。
8、監控——可以使用開源工具，如Prometheus ， Kubernetes/OpensShift, Influx DB, Apigee, Grafana, Graphite等。
9、DevOps支持—可以使用最先進的DevOps工具(如GCP、Kubernetes和Jenkins的OpenShift)來解決微服務部署和支持相關的挑戰。
10、容錯——如果給定SLA/ETA的API沒有響應，可以使用Netflix Hystrix進行熔斷處理。
閱讀更多 程序你好 的文章
