困局
? ? ? ? 隨著面向服務(wù)架構(gòu)（SOA）以及微服務(wù)設(shè)計模式的興起與流行琅轧，越來越多的技術(shù)公司投入到轟轟烈烈的系統(tǒng)升級改造的浪潮中，以換取更快交付軟件踊挠、更快響應(yīng)變化的能力乍桂。在這樣的背景下，服務(wù)數(shù)量以始料未及的速度快速攀升效床，隨之而來的就是帶來了一系列的問題睹酌。
? ? ? ?當(dāng)服務(wù)數(shù)量達(dá)到百萬級的境況下，原本很多不凸顯的問題忽然變得很凸顯剩檀，原來感覺不是很制約效率的過程變得很費時費力憋沿。
? ? ? ? 傳統(tǒng)的服務(wù)管理很多情況下是采用Excel/Word文檔來管理，服務(wù)數(shù)量可控的情況下這樣的方式應(yīng)付起來游刃有余沪猴，但是當(dāng)服務(wù)越來越多辐啄、迭代越來越快、組織越來越復(fù)雜运嗜，忽然發(fā)現(xiàn)問題來了：首先壶辜，面臨的是接口的編輯成本問題；其次担租，服務(wù)的共享砸民、更新的時效、版本的管理的難度越來越高奋救；不同的團(tuán)隊不同的文檔風(fēng)格阱洪，項目溝通、組織調(diào)整等等團(tuán)隊融合的過程增加了顯性的溝通理解成本菠镇；作為服務(wù)提供者而言冗荸，服務(wù)變更后通知關(guān)聯(lián)方的難度可想而知。由此時常引發(fā)不必要的生產(chǎn)問題利耍。
? ? ? ? 服務(wù)越來越獨立蚌本，接口越來越多盔粹，但是該有的服務(wù)上下游依賴關(guān)系還是存在，常常出現(xiàn)聯(lián)調(diào)過程中調(diào)用方需要被動等待服務(wù)方進(jìn)展程癌，當(dāng)然也不是沒有解決方案舷嗡，打樁能夠很好的應(yīng)對這樣的情況，但是如何減少打樁的成本嵌莉、減少打樁對代碼的侵入性进萄、提高打樁的可復(fù)用性又是痛點頗多。
? ? ? ? 版本迭代越來越快锐峭，服務(wù)變化越來越頻繁中鼠，自動化測試案例的編輯維護(hù)成本以及功能測試投入的回歸的成本越來越高。
? ? ? ? 凡此種種引發(fā)了研發(fā)過程一連串的問題沿癞。
破局
? ? ? ? 隨著問題的凸顯以及因此帶來的各種不可控的研發(fā)過程以及生產(chǎn)問題援雇，統(tǒng)一服務(wù)管理標(biāo)準(zhǔn)勢在必行。
? ? ? ? 顯而易見椎扬，研發(fā)中的各類角色惫搏，包括項目管理、產(chǎn)品蚕涤、架構(gòu)筐赔、開發(fā)、測試對于服務(wù)管理的標(biāo)準(zhǔn)化揖铜、高效化川陆、自動化訴求都是高度一致的，本著提高研發(fā)效能蛮位、輔助優(yōu)化研發(fā)流程的價值目標(biāo)较沪，專業(yè)的服務(wù)管理平臺級解決方案有利于突破上面描述的各類問題解決。
怎么開始失仁？
? ? ? ? 萬事開頭難尸曼，從何處著手解決問題，如何保證解決問題的思路和方案是正確的萄焦、保障成果是有效的控轿，如何快速快速突破實現(xiàn)價值。那我們首先來分析下產(chǎn)生服務(wù)管理訴求的原因：
? ? ? ? ?隨著領(lǐng)域驅(qū)動架構(gòu)拂封、持續(xù)交付茬射、微服務(wù)架構(gòu)的火熱，越來越多的巨石架構(gòu)應(yīng)用被拆分為微服務(wù)架構(gòu)應(yīng)用冒签，這種架構(gòu)的優(yōu)點很顯而易見：易擴(kuò)展在抛、易部署、易開發(fā)萧恕、易獨立測試刚梭，但是不足也隨著產(chǎn)生：
- 為了保證服務(wù)的獨立和解耦肠阱，服務(wù)被拆分的很多很細(xì)，數(shù)量眾多朴读；
- 系統(tǒng)間的調(diào)用鏈路非常復(fù)雜屹徘，集成調(diào)試?yán)щy；
- API風(fēng)格多樣：為適應(yīng)不同場景的需求（封裝性衅金、服務(wù)契約噪伊、自治性、延遲氮唯、異常鉴吹、消息編碼），采用多樣的API風(fēng)格您觉，常見的風(fēng)格有RPC拙寡、REST授滓、GraphQL琳水、服務(wù)端驅(qū)動。
- 服務(wù)治理難度加大
服務(wù)管理面臨的挑戰(zhàn)
正如上面描述的這些問題般堆，在當(dāng)前的微服務(wù)架構(gòu)模式之下在孝，需要建立健全服務(wù)管理能力，那我們面臨哪些挑戰(zhàn)呢淮摔？
1. API接口文檔編輯維護(hù)工作量大私沮，經(jīng)常升級維護(hù)；
2. 文檔標(biāo)準(zhǔn)規(guī)范不統(tǒng)一和橙，每個人輸出的接口文檔都不盡相同仔燕，后期溝通、維護(hù)會是很大的時間成本魔招；
3. 檢索查詢困難晰搀，很多傳統(tǒng)方式依賴文件系統(tǒng)管理服務(wù)，只能通過**ctrl+f**的形式來查詢關(guān)鍵字办斑，同時也不支持模糊檢索外恕、縮寫等形式，服務(wù)越多越難查詢乡翅；
4. 服務(wù)風(fēng)格的多樣性適配：RPC鳞疲、REST、GraphQL蠕蚜、服務(wù)端驅(qū)動等多種類型的服務(wù)尚洽，如何提供便捷高效的管理支撐；
5. 服務(wù)版本的復(fù)雜度：多個版本的兼容/不兼容升級靶累，如何有效管理翎朱；
6. 服務(wù)的依賴管理：面向服務(wù)架構(gòu)的推行使得服務(wù)上下游依賴關(guān)系異常磅礴復(fù)雜橄维，如何有效實現(xiàn)可視化管理；
7. 服務(wù)數(shù)據(jù)的時效性拴曲、有效性：高速的迭代下争舞，如何識別服務(wù)契約是否已經(jīng)失效，確保服務(wù)可用性澈灼；
8. 研發(fā)測試過程的支持：如何支撐快速迭代下的自動化測試能力竞川。
面對這些挑戰(zhàn)，我們?nèi)绾未蛟旆?wù)管理能力呢叁熔？下面我們就來具體的聊一聊服務(wù)管理相關(guān)的解決思路委乌。
服務(wù)管理的解決思路
1. 平臺化：以系統(tǒng)/平臺支持在線管理服務(wù)，更好的支撐共享和版本管理的訴求荣回；
2. 可視化：以可視化的方式支撐報文的入?yún)⒊鰠⒃饷常沟媒Y(jié)構(gòu)更易于使用和理解；
3. 自動化：自我發(fā)現(xiàn)服務(wù)新增心软、變更壕吹、調(diào)用鏈路等信息，減少人工維護(hù)工作量的同時杜絕因服務(wù)升級導(dǎo)致的上下游系統(tǒng)問題删铃；
4. 規(guī)范化：規(guī)范服務(wù)的生命周期管理耳贬；
5. 增值化：提供服務(wù)測試、mock能力猎唁，集成項目管理等能力咒劲，為塑造DevOps能力提供基礎(chǔ)支撐。
