最近，有許多微服務領域的討論，但是這些討論大多都是關于如何從頭開始構建微服務應用的，Mark Little認為，微服務的初衷在于改造已有的應用，提高其敏捷性，他討論了在這種場景下，實現微服務的最佳實踐。
Mark Little博士是Red Hat中間件部門的工程副總裁，他領導著JBoss的技術方向和研究/開發工作。在此之前，他曾經擔任過SOA技術開發的主管，并負責標準的制訂。
在Mark Little最新的一篇博客文章中，他回顧了自己從事微服務相關的一些經歷和對微服務的認識，他依然愿意在這個領域不斷思考，并與其團隊成員進行交流，從而推動行業思想的發展。
在這個過程中，有些困擾他的問題變得逐漸清晰。長期以來，人們思考的可能是微服務與SOA、分布式系統以及DevOps的關系，而且也有很多的項目和產品來幫助開發基于（微）服務的架構。但是，除Red Hat以外，大多數關于微服務的文章都是從頭開始構建的。這其實也反映了大多數開發工作的關注點：從頭（Greenfield）開發，重新對系統進行架構，然后完全重建。
不過，微服務最初并不是這樣的，如果讀一下最初的文獻的話，尤其是來自Netflix的文章，就會發現微服務的理念（或者Adrian Cockcroft最初所說的“Adrian Cockcroft”）是與已有系統息息相關的，它致力于將它們重構為組件（服務），這些組件能夠獨立地部署、版本化和發布。這里的理念在于為已有的系統（brownfield）構建微服務。Mark Little雖然一開始就知道這些背景，但是一直以來他始終認為這種方式與從頭開始構建所使用的過程、工具以及方式都是完全相同的。直到最近，他才意識到中間的差別。
有些團隊會基于已有的系統進行改造，實現微服務，這是很有價值的。大多數人所面臨的都是已有的應用，就像Netflix那樣，因此這種方式更具有實用性。它不需要我們好高騖遠，每次只需進步一點點即可，這方面是作者以前所沒有太多關注的。為了支持這些微服務，也需要對基礎設施進行一些很重要的簡化。
在一個樣例中，他們所面臨的是單體應用中的已有組件。因為團隊是基于Java EE的，所以具體的表現形式就是多個WAR（Web Archive）或JAR（Java Archive），這些文件會放到一個EAR（Enterprise Archive）中，但是這個例子本身與編程語言和框架是無關的。在這個例子中，目標是將單個組件拆分為微服務，這樣當某個WAR中的內容發生變化的時候就不需重新創建整個EAR包了。
如果從完全重建的角度來看，這其實沒有實質性的不同。不過，在分布式場景方面，我們可以采取一些變化，至少可以進行簡化，這里不需要命名服務（或類似的機制）來定位各種各樣的服務所在的位置，同時也不需要SLA。實際上，因為我們知道服務的API，并且這里的目標在于提升開發過程的敏捷性，所以，可以將API硬編碼到“客戶端”中（應用的其他部分）。從事后來看，很多地方都是可以硬編碼的。可以借助地址綁定或底層的網絡，如REST/HTTP使用URL來表示服務的名稱/地址，當然，這樣的話需要DNS實現綁定。
到目前為止，這是可行的，到一定程度之后，就會引入傳統分布式系統的復雜性了，不過，我們還沒到那一步。團隊的關注點在于：“作為開發人員，我該從哪里開始擁抱微服務呢，在不開發、不安裝過多基礎設施的前提下，該如何取得成功呢？”。Mark Little認為這種方式的簡化/硬編碼/依賴基礎設施能夠在一定程度上提供幫助。
當提到微服務時，我們經常讀到的內容就是中心化的日志、事件驅動方式、協作（orchestration）以及部署技術，但是，當面臨預先定義的組件/服務時，如果我們想借助微服務來提升敏捷性的話，這些技術其實并沒有那么重要。借助硬編碼以及一些自動化的方式，完全就能實現。
這是一種新型的微服務嗎？事實上并非如此，這是一種不斷演化的方式，其實與之前的CORBA和Java EE應用并無分別，我們會通過硬編碼、接口的方式進行手動編碼，隨著分布式應用復雜性的不斷增長，開發人員需要基礎設施和工具的更多幫助。所以，這種方式毫無疑問也是微服務，因為它的目標依然是讓團隊更加靈活、具有獨立的生命周期，只不過它更加聚焦于某一點，或者說更加實用。
在將已有的系統往微服務架構改造的過程中，Mark Little所述的這些觀點，應該會對我們提供一些借鑒和幫助。
京公網安備 11010502049343號