嘉賓 | 暢捷通技術總監 熊昌偉
暢捷通公司是用友旗下成員企業，專注服務於小微企業，對於各種經營階段、各種型別的小微企業，暢捷通都有產品及功能覆蓋，而且付費模式也非常靈活。
小微企業客戶有一個特性，他們的需求會特別廣泛，而且很雜，但有時用到某個產品的某類功能時，又會用得比較深入，這種情況對於暢捷通這樣標準的 SaaS 服務廠商提出了比較大的挑戰。因此，暢捷通後端需要有一個非常大的微服務群，為客戶的業務提供支撐和保障。
早在2012年，暢捷通就採用了微服務的混合雲模式。2015年，暢捷通開始將線下IDC機房全部轉換為公有云為主、IDC為輔的運營模式。到2016年，暢捷通公司基於阿里雲原生產品開始了雲原生實踐。如何藉助阿里雲強大的 IaaS 和 PaaS 能力去構建新一代的 SaaS 企業應用，從而給客戶提供更好、更強的服務，這是暢捷通一直在思考和實踐的方向。最終，暢捷通選定阿里雲企業級分散式應用服務 EDAS 作為應用託管平臺，並開始下一代產品的微服務開發。
為什麼選擇阿里雲？暢捷通的優勢在於業務創新，在技術服務和技術能力的建設方面，公司傾向於選擇一個可靠的基礎架構平臺，因為 To B 業務的穩定性是核心能力，阿里雲是我們的第一選擇。
暢捷通從雲原生中獲得技術紅利從一開始，暢捷通就把雲上所有的應用都部署在雲上的ECS，後來出於成本的考慮，又把一部分研發環境和測試環境也搬到雲上容器環境，再借助監控服務ARMS、訊息服務、日誌服務等阿里雲應用，以全面的雲原生產品來提升產品研發的效率與雲上應用的穩定性。
起初，整體的研發模式都非常流暢，效率也很高，但是基於微服務架構構建的業務系統在帶來便利性和靈活性的同時，也給開發團隊和測試團隊帶來了挑戰。因為微服務之間存在依賴，開發人員無法在本地完成開發和測試工作，必須依賴於一套完整的開發測試環境，但同時每一套環境又是隔離的，這時就出現了三個痛點：
事多，多個開發人員和測試人員共享一套環境，相互影響，除錯困難。由於微服務上下層之間的依賴，整個環境中如果有一個微服務出現問題，整套環境就無法正常執行。當開發人員想要除錯某個功能，又必須依賴於上下游的應用呼叫時，就會非常痛苦。每增加一個微服務，整體的研發效率就在下降，這時的情形與暢捷通最初採用微服務的目標背道而馳。錢多，構建多套開發測試環境，成本很高。最初因為要加快進度，暢捷通會不計成本地部署多套環境（一套完整的微服務呼叫環境，一年費用10萬元起步），這個成本對於正常盈利的公司而言還是比較高的。當時暢捷通的研發環境和生產環境的比例達到了 4:1，這是什麼概念呢？就是暢捷通需要用花費 400 萬的研發環境，才能研發出只要 100 萬就能支撐所有客戶的生產環境執行的應用，這個費用比非常可怕。人多，繼續增加環境，維護成本激增。在開發人員和測試人員隨研發目標擴大而持續投入的情況下，為了匹配微服務的需要，暢捷通需要持續地增加後臺環境的維護人員，比如運維人員或者相關的保障人員，而且他們的工作量成倍增加，因為微服務出現故障或者環境出現問題是非常常見的事情。針對暢捷通的痛點，阿里雲設計併發布了 EDAS 全鏈路流控方案：在微服務場景下可以對流量進行精確控制，在入口處根據指定的特定特徵進行流量識別，同時標識會隨著這個請求在整個執行流程中進行流轉，這樣可基於標識對微服務呼叫進行精確控制，將特殊流量引導到特定的應用版本或環境。
全鏈路流控流程示意
如圖所示，使用者的一個標準請求在前端應用可以轉發時，它會在基線環境中進行流轉。在請求中加入標識，比如v1.1版本，它會流轉到微服務 A 的v1.1版本。當請求繼續流轉，且沒有出現v1.1版本時，它會回到基線版本，而出現v1.1版本時，它又會繼續流轉到 v1.1版本。透過這樣的模式，可以用少量的環境去支撐大量的特性開發。
但此時還存在兩個問題，一個問題是後端的微服務經常變更，前端的應用和服務也在變更，那麼變更該如何解決？另外一個問題是，每個開發人員都在服務層做除錯和釋出，當他們把應用釋出到伺服器上再進行呼叫，成本其實還是比較高的。
針對這些問題，暢捷通跟阿里雲的技術人員一起調研試錯，最後引入了微服務閘道器策略，搭建了基於全鏈路流量的開發測試環境。透過微服務閘道器的能力，就能實現前端和後端全部灰度的模式，按需部署，節省了大量的費用，也大大降低了運維成本。同時也實現了多環境的相互隔離，業務之間相互不影響。
在實踐過程中有一個獨特的亮點，這就是微服務閘道器策略中的端雲聯調模式：開發人員可以將本地的膝上型電腦直接註冊到整個微服務環境中去，這樣開發人員就可以在本地完成上下游業務的驗證和測試，極大地提高了開發人員的工作效率以及提交程式碼的質量。而在這之前則是在本地模擬一些請求，去猜測微服務環境上下游的呼叫是否正常，並沒有一個真正的環境去做驗證。現在透過端雲聯調模式，就可以方便地將膝上型電腦註冊到整個服務中心去進行流轉，包括前端應用的管控。與此同時，透過微服務閘道器策略，不但實現了南北向的流量管控，也實現了東西流量的全管控模式。
另外，暢捷通還透過接入阿里雲應用實時監控服務 ARMS，讓暢捷通微服務體系具備了監控能力。在此之前，由於暢捷通 SaaS 產品涉及到的業務鏈路極為複雜，當用戶反饋系統出現 bug 或者效能存在問題之後，團隊需要耗費非常長的時間在錯綜複雜的鏈路之間定位故障源以及效能瓶頸。
但是，接入 ARMS 之後，透過全鏈路資訊排查、應用實時診斷等工具，可以將定位問題的工作量降到之前的50%以下，極大地提升了團隊的工作效率。後續隨著暢捷通各條業務線的持續迭代，在整體微服務架構中也逐步引入了訊息服務 MNS、應用高可用服務 AHAS、效能測試 PTS 等一系列雲原生產品，進一步解放了團隊的生產力，使得暢捷通有更多的精力來更好地滿足使用者的業務需求。
透過引入成熟和穩定的阿里雲原生產品方案，暢捷通的系統架構在面對複雜業務場景頻繁迭代時，表現出了穩定、健壯、彈性的優勢。暢捷通的研發團隊也透過在實踐中建立並掌握了一套方法論，形成適合自己的微服務治理機制，又繼續實踐著全鏈路灰度等全新的微服務治理思路，在降本增效的同時，也體現出暢捷通在企業管理雲服務領域領先的研發管理水平。
暢捷通的業務正在高速發展中，雲原生產品像一個強有力的助推器，加速企業的創新升級。
雲原生的價值對於大部分企業來說，IT 是有歷史包袱的。因為原來 IT 應用的部署模式都是豎井式的，不同應用由不同的軟體開發商提供，系統之間存在網路安全隔離，又存在協同關係，網路、應用拓撲非常複雜。所以企業 IT 上雲是一個系統性的工程，原來的應用可能還需要結合雲上提供的虛擬機器、網路和儲存的特點進行必要的改造，不能簡單粗暴的使用“原來物理機什麼配置，虛擬機器就什麼配置。原來應用什麼架構，上雲後就什麼架構”的這種失去“上雲”優勢的遷移方法，要防止為了上雲而上雲的做法。
雲的特點就是彈性、敏捷、分散式、可擴充套件、自管理、自恢復，符合雲特點的基礎架構就可以稱為雲原生基礎架構。雲原生基礎架構需要在提供自主應用程式管理的 IaaS 之上建立一個平臺，這個平臺要建立在動態建立的基礎架構之上，以抽象出各個服務，並促進動態資源的分配、排程和擴充套件。
雲原生是一種構建和執行應用程式的方法，它充分利用了雲計算交付模型的優勢，更天然的貼合雲的特點。雲原生既包含技術（微服務、敏捷基礎設施），也包含管理（DevOps、持續交付、康威定律、重組等）。雲原生是一個不斷豐富的理念和技術體系，它在基礎架構、應用程式和管理上都將深刻的影響和改變企業雲的未來。
在不斷的應用探索並持續改進後，雲原生產生了多種核心價值。
第一，其優勢和雲的傳統優勢（如：資源池化、規模化、穩定性和彈性）完美結合，為企業提供了更好的產品和服務，降低了上雲成本，並驅動了雲的進化，如：軟硬一體協同最佳化。同時透過aPaaS、雲原生中介軟體、微服務、服務網格、Serverless 等產品技術，讓雲平臺的使用介面不斷上移，進一步降低雲的使用成本，提升技術效率。第二，雲原生技術基於開放的標準，極大地改變了使用者心智，促進了企業和開發者對新技術和上雲的接受度，雲原生成為雲和客戶互動的新介面。另外，雲原生是應用研發和系統運維最佳實踐的組合，正在重塑軟體生命週期，透過基礎設施雲化、核心技術網際網路化、應用資料化以及智慧化來賦能企業，為企業帶來降本增效、快速迭代、智慧運營的優良基因，促進了企業生產力，助力企業的業務增長和商業創新，幫助企業快速獲取技術紅利，加速企業的數字化升級。
運維已去，技術運營已來因為雲原生能力帶來的價值，很多企業開始基於雲原生做技術架構調整。不僅如此，為了讓雲原生更好地發揮價值，企業的組織架構也會隨之改變。在暢捷通，技術運營成為組織中很重要的一部分。
很多人都在好奇技術運營與運維的差異？其實技術運營是從被動的運維保障轉變為主動的技術服務。有價值的技術運營領域應該思考：如何促進產品的成熟？如何發揮技術的價值？如何為使用者帶來感動？如何讓技術運營成為企業的另一個核心競爭力？所以，技術運營更多時候應從財務管理的視角進行判斷和決策，從商業角度控制成本投入和分配，以獲取資源利用率和營收最大化。換句話說，就是從客戶真正的痛點出發，平衡的駕馭“穩定、安全、容量與成本”，用創業的心態做產品，用花自己錢的心態去運營。
此時的技術運營，不再是傳統的運維管理方式，他們會從業務目標出發來評估投入產出比，包括資源利用率，甚至是每個客戶的資源成本等，將成本意識完全植入到研發執行體系中，讓每一位開發人員都清晰的瞭解到業務資源的成本，以合理申請公司 IT 資源，最終提升整體的研發能效。
而暢捷通之所以會產生運維崗位向技術運營崗位的升級，與雲原生有很大的關係。
回顧暢捷通的上雲歷程，上雲之前，暢捷通更關注系統的穩定執行。上雲之後，暢捷通會更關注產品如何給客戶提供更好的體驗。以前我們的DBA、網工每天忙得不可開交。但上雲之後，大家在基礎層面的工作大大減少。比如從資料庫的角度，之前大家會關注資料庫的主備切換、備份等，現在大家則關注資料庫的執行狀態是否健康、慢SQL如何最佳化等。另外在組織架構層面也有很大的變化，上雲之後，基礎運維的同學大幅減少，而開發人員規模大幅增加。現在暢捷通的組織裡已經沒有運維崗位，他們被大家稱為“運維開發”。
在這個升級變化的過程中，實質上還是思維方式的一種轉變。
這個轉變包含很多層面，既包括員工的意識形態及技能的變化，也涵蓋著公司對於整個技術運營部門的重新定位和價值升級。
原來在做更新上線時，都是由運維同學來負責，經常需要幾個通宵，而現在則是由研發同學透過自助來完成，不再是人力的交付，而是系統的支撐和平臺的交付，這也是熊昌偉在暢捷通轉型過程中一直在給大家傳遞的理念。所謂系統性交付，就是一項工作你可以做一次、兩次，但如果你需要重複做三次以上時，你就應該把這部分工作交付給產品或系統，讓它們來實現這些能力。
轉型不易，對於運維崗位而言是很大的挑戰。
首先是思維模式的轉變，原來運維是作為系統保障的核心，每個運維人員的後面都會跟著很多的開發人員和測試人員。現在隨著雲原生產品的引入，整個運維的壓力大大降低，對於運維人員來講就需要提供更多的主動服務，來體現自己的價值，而不是被逐漸邊緣化。其次，運維人員要有意識地進行轉型，現階段我們有很多人開始做技術運營，後面大家還會更深入地成長為系統架構師、雲架構師等。對於每款引入的雲原生產品，技術運營都要成為公司裡最懂怎麼執行好這款產品的專家。雲產品的使用方式跟傳統的產品肯定不一樣，比如上雲之前不需要關注網路層面，但是上雲之後有了一些新的概念，比如跨區訪問、計量模式等。雖然阿里雲可以保障雲產品基本的穩定性，但是這款產品如何用得更好、當前狀態怎麼樣、產品在服務客戶過程中是否穩定等，是需要技術運營人員持續思考和不斷實踐的。雲原生，讓專業的人做專業的事熊昌偉不斷強調：“我理解的雲原生，就是讓專業的人做專業的事。”
聚焦於自己的專業領域，把自己的優勢發揮到最強。不要為了表面上的“省錢”（實踐證明自建相較於雲產品的綜合成本更高），而忽視了服務的穩定性。
很多技術人員會說自建更好，我們有自己的技術人員，為什麼不自己建一個平臺或者搭一個伺服器？
實際上，如果自建出現了任何故障，一樣會給整個業務帶來很大的損傷；另外從技術人員的角度，他們“只管生不管養”，雖然交付不容易，但執行過程中持續的維護和使用才是更核心的。在我們已知的行業過往中，除非技術人員非常厲害，否則自建的成本非常高，而且最後基本都“慘敗收場”，轉而開始使用雲產品。
暢捷通是業內較早意識到雲原生產品價值的企業之一，也是較早踐行雲原生理念與落地雲原生實踐的企業。
暢捷通為什麼相信雲原生？
首先，暢捷通願意擁抱新趨勢，在公司層面會對業內前沿的技術和產品做調研，切實地計算出雲產品與自建之間的差距，包括成本、效率、穩定性等維度。比如“如果用阿里雲原生的產品，投入是多少，產出是多少，盈虧平衡點等”。經過測算髮現，隨著業務量的增加，整體的紅利會越來越大。
其次，暢捷通在做產品選型時非常的謹慎，因為這個產品一定要經得起考驗，才會讓大家感受到產品的好處，從而建立信任。這其實也是暢捷通選擇阿里雲的原因，因為阿里雲原生產品的打磨和在複雜場景中的歷練都非常的完善，產品使用過程中給暢捷通團隊的整體感受也很好。技術運營團隊其實是阿里雲與暢捷通之間的一道橋樑，讓好的產品在暢捷通發揮出它的價值，同時也讓暢捷通享受到雲原生的技術紅利。
變化莫測、快速前行的時代，我們既要敬畏技術，更要擁抱新的趨勢。就像我們身邊的通訊行業裡，很多手機廠商用最好的硬體、螢幕、晶片甚至是按鍵等來打造出一款優秀的手機，並完成生態的建設。雲原生的模式也是如此，越早加入這個趨勢，無論對於公司業務的支撐和助力，還是個人的可持續發展，都會更加長遠。
接下來，暢捷通也計劃透過 EDAS+ACK 的方案，實現快速的容器化以達成基礎設施及應用的全面雲原生。EDAS3.0 是一套 PaaS 平臺，提供 ECS 與 K8s 的雙模應用部署交付模式，助力暢捷通從容實現容器化落地。