1.1　微服務面臨的挑戰

微服務的粒度影響服務的交付速度及擴展性，微服務的開發引入治理組件，增加了開發的難度，以容器為基礎的微服務基礎設施在彈性等方面仍有不足，而微服務增加帶來的基礎設施成本也是微服務實施的新挑戰。

1. 微服務的粒度仍然比較大

當前微服務劃分主要遵循單一職責的原則，比如將用戶管理的功能作為一個單獨的微服務。如圖1-1所示，用戶管理微服務提供了API注冊、登錄、登出功能。通常，從提升用戶體驗的角度來看，瀏覽器會保留用戶的會話，除非用戶主動登出，否則不會請求登出API。所以，登出和注冊的QPS差距較大，對擴展的訴求完全不同。而且，注冊API和登出API的變更頻率也可能不同。進一步拆分可以帶來擴展性等便利，但整個微服務的數量也會提升一個量級，給基礎設施的管理帶來負擔，那么如何做好架構權衡，既能夠擁有架構上的高可擴展性，又不用增加基礎設施管理成本呢？

2. 微服務開發仍有較高門檻

如圖1-2所示，Java微服務開發的軟件棧要求開發者掌握以下技能。

相比于單體應用開發，微服務開發效率得到提升的部分來自服務粒度減少及開發框架的改進，例如，從復雜的SpringMVC演進到SpringBoot，框架更加輕量化。但在其他方面（并發處理等）并沒有什么改變，同時在微服務治理、分布式事務等方面的開發難度反而增加了。服務網格的出現，讓開發人員可以不用關心服務治理的內容，但這樣會帶來服務性能的下降和維護的復雜性，其使用的范圍也存在局限。是否存在一種新的編程模型及開發框架，讓開發者在了解基本的語言特性和編程模型后，便可上手開發業務邏輯，而不用關心網絡、并發、服務治理等問題？

3. 微服務基礎設施管理、高可用和彈性仍然很難保證

容器和Kubernetes工具的使用，提升了應用部署及基礎設施運維自動化的能力，但保證基礎設施高可用、可擴展對運維人員的能力要求很高。如圖1-3所示，服務上云后，基礎設施團隊可以不用再關心服務器、交換機等硬件的運維，但仍然需要關心虛擬機的維護，如安全補丁、基礎鏡像的更新升級、擴容等。

從On-Premise到公有云，實際上虛擬機的可用性在降低，比如云服務商提供的單虛擬機的可用性可能只有95%。運維人員需要借助云側的工具來保證基礎設施的高可用，難度仍然存在，而且很依賴運維人員的能力。

集群及其他云原生工具的維護也帶來額外的挑戰。以Kubernetes集群為例，維護和管理Kubernetes集群需要專業的技能。同理，維護云原生的監控、日志服務的高可用性也有不小的難度。所以，基礎設施管理的難度仍然存在，只是從虛擬機轉移到容器集群，從Rsyslog轉移到ElasticSearch。

對于服務層面的擴展性，當前的策略也比較簡單，例如，設定最少和最多使用的虛擬機數量，或者想辦法改善根據CPU/內存使用率來伸縮或擴容的延遲。但是，由于總體資源量不會超過策略設定的虛擬機極限數量，因此一旦請求超過最大資源能承載的范圍，可能會影響用戶的使用體驗甚至會服務中斷。以容器為單位的擴容，從虛擬機性能的分鐘級減少到30s左右，但當面對突發流量時依然會出現響應不及時、用戶體驗差的情況。是否存在全托管的基礎設施及監控運維服務，能提供更好的彈性，從而讓開發者無須關心所有底層和集群的維護工作，不再依賴高級運維人員來保證基礎設施的可用性？

4. 基礎設施的成本依然較高

微服務會增加基礎設施的成本。每個微服務都要考慮冗余，保證高可用。隨著微服務數量的增加，基礎設施的數量會呈現指數級增長，但云服務的基礎設施收費方式沒有改變，依然采用按照資源大小及以小時為單位（或包年）計費的方式。閑時和忙時的收費相同，對企業來說存在成本的浪費。是否存在一種新的基礎設施服務，能按照“用多少付多少”的方式收費，從而降低基礎設施成本？

微服務面臨的這些新問題，是否可以通過新的基礎設施服務及開發模式來解決呢？