如果您打算對當前的微服務實現(xiàn)進行自己的檢查，則絕對應該閱讀本篇文章了。

您的公司將從微服務實施審核中受益嗎？

我們的許多客戶當前正在使用基于“微服務”的架構來實現(xiàn)應用程序。我們越來越多地從公司遷移到微服務的過程中聽到他們的聲音，他們需要我們的幫助來驗證和改進其當前解決方案。這些“微服務檢查”項目揭示了一些有趣的模式，并且由于我們具有在廣泛行業(yè)中工作的經驗（并且在查看項目時也有“新鮮的眼睛”），因此我們經常能夠與團隊一起工作以進行重大改進，并為將來的改進制定戰(zhàn)略路線圖。

我們在下面總結了我們的發(fā)現(xiàn)，目的是在您考慮對自己當前的微服務實現(xiàn)進行檢查時提供啟發(fā)。

技術基礎

2014年，Martin Fowler表示 成功實現(xiàn)微服務的 前提條件包括快速配置，基本監(jiān)控和快速應用程序部署。OpenCredo團隊在內部進行了長時間的討論，我們不僅廣泛同意該聲明，而且在多個項目中也對此進行了驗證。

快速配置

隨著微服務平臺，微服務兼容平臺即服務（PaaS）和容器即服務（CaaS ）（ 如 Kubernetes，  Mesos 和 Docker  Datacenter ）的實現(xiàn)，快速配置在2016年變得不再那么重要了 。這些平臺通常提供可將微服務部署到的計算資源的同質化池（或其他某種抽象化）。但是，某些公司選擇部署到基礎架構即服務（IaaS），例如Amazon Web Services  （AWS），  Google Cloud Platform提供的 服務。 （GCP）和Microsoft Azure，這里缺乏快速配置是導致開發(fā)和運營之間經常發(fā)生爭執(zhí)的原因。

作為微服務檢查項目的一部分，我們通常會尋找警告信號，例如不可重復的構建，手動組裝基礎結構以及配置漂移（令人恐懼的“雪花服務器”）。OpenCredo的團隊是容器技術和相關業(yè)務流程平臺的支持者。我們也是HashiCorp工具的愛好者，并定期與Packer 和 Terraform一起工作（并為它們做貢獻）  。盡管HashiCorp致力于爭取世界統(tǒng)治，但我們當然意識到確實存在其他配置管理工具，并且我們與Ansible，  Puppet 和 Chef進行了大量合作 。

基本監(jiān)控

監(jiān)視微服務實現(xiàn)的能力確實至關重要。隨著在應用程序中部署的服務數(shù)量的增加，交互的復雜性也 隨之增加，因此，潛在的 突發(fā)行為成為現(xiàn)實（這是真正復雜的系統(tǒng)的標志）。作為微服務檢查的一部分，我們尋找諸如未檢測到的基礎結構問題（例如磁盤空間用完），警報風暴（觸發(fā)了太多警報以致無法知道問題的原因）和生產中斷等問題。 。

我們定期與客戶合作，以幫助集成和配置SaaS監(jiān)視解決方案（例如 Datadog，  Sysdig 和 Ruxit），并且還與本地監(jiān)視解決方案（例如 Prometheus）合作。我們也是合成交易 和關鍵煙霧測試的堅定支持者， 并且 為此目的使用了諸如JMeter 和 Serenity BDD之類的工具 。通常，當我們向項目經理和其他業(yè)務涉眾展示此內容時，他們會想知道如何在不具有應用程序可見性的情況下進行管理！

快速的應用程序部署

快速應用程序部署的主題以及持續(xù)交付的相關主題 ，應有自己的博客文章。但是，在微服務檢查的背景下，我們經常發(fā)現(xiàn)這是采用微服務的公司中大多數(shù)爭執(zhí)的原因。我們中的許多人習慣于使用諸如Jenkins，  Go CD 和 Spinnaker之類的持續(xù)集成和部署工具 ，但是當成功執(zhí)行構建流程時，我們經常會看到公司內部出現(xiàn)問題。  一個團隊中的成員應用于公司中的另一個團隊。如果無法在整個公司中可靠且重復地部署構建，或者生產中斷頻繁，那么我們將進一步研究為可擴展的快速應用程序部署提供支持。通常，必須在技術和公司級別解決與該問題相關的問題。

我們看到的另一個常見模式是，最初的微服務實現(xiàn)或概念證明不與“傳統(tǒng)”（賺錢）系統(tǒng)集成，因此，在這種情況下實現(xiàn)持續(xù)交付的痛苦并沒有經歷。我們經常與 SpectoLabs 團隊合作解決此問題，因為他們在解決此問題（例如服務虛擬化 和 API仿真）方面擁有豐富的經驗 。

不要忘記公司

對于那些使用微服務Bingo的人來說，這是您檢查“ Conway法則”的地方。但是，正如我們在其他文章和演示中所討論的那樣，實際情況是 Conway在說實話……

公司設計與轉型

當團隊從概念驗證階段過渡到實施階段時，通常會出現(xiàn)公司設計斗爭的最初跡象。如上面“快速應用程序部署”部分所述，一旦實現(xiàn)擴展到一個團隊之外，那么交互的復雜性就會增加。這通常在技術層面上具有挑戰(zhàn)性，但在公司層面上幾乎總是具有挑戰(zhàn)性 。我們會尋找危險信號，例如工作隊列，長時間的延遲或工作在公司中移動時出現(xiàn)的“信號中斷”，以及團隊朝不同的方向（或使用競爭技術）拉動。

我們已經 幫助多家公司 從開發(fā)團隊到產品團隊，再到管理層，回顧了他們當前的目標設定和公司結構方法。我們經常與公司內部的C * O級別一起工作，因為除非在此級別上達成一致和認可，否則公司其他部分進行的任何更改都可以輕松地解決。

“ DevOps”的重要性

盡管“ DevOps”一詞  已經過分使用（但仍未 真正定義），但我們相信其背后的概念，例如（1）跨開發(fā)和運營共享理解和責任，（2）自動化，遵循原則驅動工具的實踐，而不是相反的做法，以及（3）創(chuàng)建用于快速反饋的信號，對于微服務架構的成功至關重要。由于基于微服務的應用程序中的應用程序組件數(shù)量通常較高（與更傳統(tǒng)的體系結構相比），我們經?？吹絾栴}迅速出現(xiàn)，團隊無法達成目標，以多種不同方式解決同一問題。 貨物養(yǎng)殖 自動化程度或對現(xiàn)成的“ DevOps工具”的錯誤使用；并且沒有 情境意識。

DevOps的技術方面已經在本文中進行了介紹，但是與上一節(jié)關注公司設計的部分一樣，DevOps的公司和人員方面同樣重要（甚至更多）。我們已經看到DevOps的實施會在公司內部引起恐懼，我們也看到次優(yōu)流程 是自動化的 （自動失敗仍然是失?。。?。根據我們的經驗，我們開發(fā)了一些程序來協(xié)助 向“ DevOps” 工作方式的 轉變。我們還認為，“ DevOps”運動背后的概念和目標對于更廣泛的業(yè)務環(huán)境和當前的經濟環(huán)境至關重要，在這些市場中，上市時間和創(chuàng)新速度是明顯的競爭優(yōu)勢。

您能從第二雙眼睛中受益嗎？

正如老套話所說，在OpenCredo，沒有兩個項目是不一樣的，因為我們?yōu)槊總€客戶和項目量身定制了我們的服務。我們的目標是進行系統(tǒng)的更改，并提供盡可能多的知識轉移，以使任何已實施的解決方案在長期內都是可持續(xù)的。話雖如此，我們已經在微服務的范圍內確定了幾大類，我們可以通過這些類別反復幫助客戶。

整體到微服務評估

您現(xiàn)在應該遷移到微服務架構，還是從另一個解決方案中受益？通常，客戶希望確保微服務能夠解決可伸縮性和性能問題，而實際上，首先必須解決基礎架構，設計和數(shù)據建模問題。

我們可以幫助您設計從 整體到微服務的 遷移策略。例如，我們可以幫助您回答以下問題：您應將現(xiàn)有功能提取到新服務中，首先應將哪些功能構建為微服務（以及如何對數(shù)據建模），以及如何將服務與遺留應用程序集成？

您是否需要有關公司如何確保為微服務實現(xiàn)做好準備的指南（從建立目標的戰(zhàn)略一致性，實施最合適的公司結構到采用“ DevOps”哲學）？

業(yè)務和公司審查

您的團隊是否了解  整個公司的價值流？OpenCredo幫助公司更好地了解了其 價值流圖，然后幫助他們（通過實驗）增強創(chuàng)新并減少了交貨時間。

您的公司是否已對“影子IT ”感到不知所措？團隊是否在創(chuàng)建微服務并將其部署到不同的平臺？OpenCredo可以提供有關如何使IT走出陰影的指南。

員工是否積極 抵制變革？我們可以幫助您了解如何改善學習和溝通。

微服務平臺/基礎架構建議和指南。

您是否想利用PaaS解決方案，但不知道選擇哪個？

您是否想將容器（Docker）引入基礎架構堆棧，但是不確定如何實現(xiàn)，部署解決方案并使之 保持運行狀態(tài)？

我們可以就Apache Mesos，  Kubernetes，  AWS ECS 和 Docker Datacenter等平臺的優(yōu)缺點提供指導 。

OpenCredo是編程基礎架構和相關工具（例如HashiCorp  Terraform 和Packer，Ansible，Puppet和Chef）的專家。我們可以確保您在整個開發(fā)和運營團隊中使用這些方法達到最佳效果。

持續(xù)交付微服務

我們可以幫助您 建立CI / CD管道 ，以支持從開發(fā) 到生產的快速交付經過測試和驗證的應用程序組件 。

我們可以幫助您驗證當前構建管道的有效性。例如，您是否必須同時部署多個服務以防止集成問題（可怕的“分布式整體”），還是您有多個手動測試驗證門？