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

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

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

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

技術(shù)基礎(chǔ)

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

快速配置

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

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

基本監(jiān)控

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

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

快速的應(yīng)用程序部署

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

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

不要忘記公司

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

公司設(shè)計與轉(zhuǎn)型

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

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

“ DevOps”的重要性

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

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

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

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

整體到微服務(wù)評估

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

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

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

業(yè)務(wù)和公司審查

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

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

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

微服務(wù)平臺/基礎(chǔ)架構(gòu)建議和指南。

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

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

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

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

持續(xù)交付微服務(wù)

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

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