成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

架構設計的理念和原則是SaaS的核心靈魂

原創 精選
云計算 SaaS
我相信,優秀的技術架構是演進出來的。這不意味著你要一個個坑重新踩一遍,我已經踩了這么多年的坑,不斷地從坑里爬出來。今天的分享就是為了讓大家少踩一些坑。或者當你準備往下踩的時候,你感覺這是個坑,你可以以開放的心態對外多交流,通過這種交流來加速你對架構的某些理解。?

作者丨安靜波

編輯丨千山

本文整理自天潤融通CTO安靜波在WOT2023大會上的主題分享,更多精彩內容及現場PPT,請關注51CTO技術棧公眾號,發消息【WOT2023PPT】即可直接領取。

日前,在51CTO主辦的WOT全球技術創新大會上,天潤融通CTO安靜波帶來了主題演講《全渠道智能客戶聯絡平臺技術架構的挑戰與演進》,為大眾呈現了全新的視角。

最近幾年,天潤融通業務從專注呼叫中心發展到全渠道聯絡平臺,并逐步與AI技術相融合,幫助企業加速高效智能化管理的轉變。這個過程不僅僅是產品功能的疊加,更是業務模式的變革和技術架構的升級。安靜波詳細介紹了天潤融通在發展過程中如何面向業務需求進行技術架構的迭代。

本文將摘選其中精彩內容,統一整理,希望為諸君帶來啟發。

一、十七年發展歷程中的四輪變革

成立于2006年的天潤融通一直以來專注聯絡中心業務。無論是最初的呼叫中心,還是發展到如今的全渠道全周期的聯絡中心業務,天潤融通在十七年間都在堅持為客戶聯絡這一場景提供服務,整個發展過程中經歷了四輪架構的重構。

階段1:2006-2012,軟交換+呼叫中心。這一階段主要完成了大規模語音交換平臺的開發和商用,具備了大規模、靈活處理語音業務的能力,與此同時,為復雜呼叫中心的產品演進建立了扎實的平臺底座。

階段2:2013-2016,云原生重構。以云技術為核心,對平臺進行徹底的原生改造,從架構上實現了大容量下的高可用,徹底突破容量瓶頸;具備異地、跨云雙活能力的平臺上線,解決了快速演進與穩定運行的矛盾。

階段3:2017-2022,全渠道+智能化。由語音呼叫中心升級為全渠道聯絡中心,具備了完備的全渠道覆蓋能力;利用基于深度學習的AI技術,對平臺進行智能化改造,構建完整的AI產品體系。

階段4:2023至今,AI原生重構。以AI技術為核心,以企業知識管理為基礎,構建“人機融合”的新一代客戶聯絡平臺;業內首家推出“客戶聯絡垂直場景” 下的大語言模型行業解決方案,同步推出一系列AI產品。

天潤融通在2018年之前就成為了中國最大的公有云客戶聯絡解決方案供應商。我認為,之所以能做到這一點的主因在于:天潤融通精準地定義了呼叫中心云服務是什么,決定性因素在于以下三點:

原生架構的云核心軟件。簡單來說,基于軟件架構+云。

云網一體的業務承載網絡。在客戶聯絡場景中,像語音這種業務必須做到實時性和高可用。任何網絡節點出現問題,軟件就沒用。因此,如何構建云網一體的業務承載網絡是產品核心的架構問題之一。

全局性高可用的云生態系統。除了軟件、網等問題外,如何進行通信資源的調度,如何用生態系統來解決高可用問題。

2018年之前,我們清晰地意識到,這三點是最核心的工作,所有的工作都圍繞這三條主線來展開。基于此,我們也獲得了客戶的認可。

面向未來,我們認定智能化將是聯絡中心未來最核心的東西。我們希望用AI和大模型去重構云聯絡的架構,進而實現實時SaaS、業務SaaS和人工智能的完美融合。

二、業務發展過程中遇到的挑戰和應對

接下來,綜合回顧一下整個業務發展過程中遇到的挑戰。我總結了其中三大最主要的問題。

  1. 如何實現大容量高可用的實時的SaaS系統。
  2. 如何應對實時SaaS和業務SaaS高復雜兩個維度的疊加。
  3. 如何在聯絡中心場景中深度融合AI能力。

1.如何實現大容量高可用的實時SaaS平臺

可歸納為兩點:端到端與全云化、全鏈路高可用架構。

所謂“端到端與全云化”,簡單解釋,即呼叫中心云服務是全鏈路的.端到端包含五個層次:系統軟件、云平臺部署、網絡接入、座席端設備,以及通信資源整合。其中任何環節出問題,平臺對客戶來講就不能用。

圖片圖片

可以看到,整個鏈條是比較長的,所以要考慮的是端到端和全域化這樣的結構,才能解決此類問題。

在高可用上,要考慮的就是六個方面的高可用:軟件架構高可用、云服務高可用、基礎設施高可用、通信資源高可用、網絡架構高可用、可持續的演進。因為SaaS服務最核心的靈魂就是可以快速創新和演進。這個創新要能服務于客戶業務的創新,如果失去了這種能力,這個平臺就“死”了。如何做到在快速升級的同時還能夠穩定地提供服務,對SaaS軟件來說至關重要。

簡要概述一下幾個“高可用”的核心要義。

軟件高可用:通過解耦、集群化、盡量使用原生的云組件、運行可度量來達成軟件高可用。另外,把架構分層,讓底層通信與應用分離。

云網一體高可用:基于支持的云很多,采用跨云、多云架構。北上深三地的核心網各自擁有兩個核心機房,六個核心機房組成南環和北環,環之間用光纖鏈接,以此來實現高可用。

圖片圖片

高可用通信資源:將通信資源能力云化和池化,話務調度系統可以根據業務變化靈活調整,應對故障及擁塞等。

高可用演進架構:支持DevOps組織結構,實現設計、開發、測試和運維一體化;關鍵應用灰度發布,而且要做兩級灰度;配套建設自動化。

2.如何應對實時SaaS和業務SaaS高復雜兩個維度的疊加

當我們能很好地保障實時,同時面臨業務拓展時,如何解決業務SaaS高復雜疊加的問題?應對策略有三點:

1)對不同業務有效分類解耦,應用不同原則。

具體來說,從業務分類來講,分為實時系統和業務系統。實時系統包括通信平臺、呼叫中心、RTC音視頻、機器人等,這些都要求在秒級甚至毫秒級有響應。相較而言,業務系統諸如CRM/SCRM、工單、知識庫更多的是考驗復雜度,考驗對業務的理解。兩者要應用不同的架構原則,最終組織結構也要匹配架構原則。

2)構建SaaS業務基礎框架,提高復用效率。

所有新業務都是從嘗試起家,但是如果沒有一些基礎模塊的支持,試錯的代價不菲。因此要構建一些基礎的、可復用的東西,作為整個公司級別的基礎設施。

構建SaaS業務的基礎框架大致可以分為7類,分別是:RAM,即統一的用戶權限體系;BOSS,即業務支撐體系;Workspace工作臺框架和微前端容器;基礎報表引擎,避免從頭搭建報表;前端可復用結構,如低代碼引擎、統一的UI規范等;運行監控體系;安全管理體系。總體來說,當業務足夠多時,有這類基礎框架,才可以快速地讓新的應用高效接入。

3)SaaS業務的PaaS化架構,構建競爭壁壘。

將部分SaaS業務做PaaS化,最核心的價值就是能幫助企業提高交付效率。關于這一點,分享幾點認知:

  • 相對2C來說,2B產品更適合PaaS化
  • “只有大公司才能做PaaS”這種說法實質是本末倒置。換言之,正因為抽象總結能力夠好可以做PaaS,才可能成為大公司
  • 選擇那些和客戶業務多樣性關聯小的做PaaS化
  • PaaS的洞見來自SaaS,是一個領域需求積累和抽象的產物。因此要長時間接觸客戶,了解其根本需求,洞察其變與不變的部分
  • PaaS化的價值體現在最終服務SaaS。最終要以SaaS業務做得如何來評價PaaS化的成效
  • PaaS對外輸出,還可以給大客戶賦能

3.如何在聯絡中心場景中深度融合AI能力

如何理解深度融合?AI在聯絡中心里的應用,并不是簡單地做語音機器人、文本機器人,而是應該理解成為,將工作的業務流和整個業務過程中的每一步全部AI化。以呼叫中心為例,從電話打進來、怎么排隊、排隊時長的預測,到接通以后如何做情緒識別、客戶標簽畫像,到通話結束以后如何進行滿意度調查,到最后做一些分析,過程里每一步都要去如何智能化。這就是我們對智能化融入到云聯絡中心,真正實現人機融合的理解。

圖片圖片

三、業務機構和技術架構原則

下面分享一下我們在實踐過程中總結下來的一些業務架構和技術架構的原則。

1.匹配原則。

  • 技術架構肯定是服務于業務的。
  • 不同的業務形態適用于不同的技術架構。比如,實時業務和非實時業務肯定是不同的。
  • 不同階段要應用不同的架構。初創階段適合什么?快速發展階段適合什么?要因時制宜。

2.穩定和創新相結合。

  • 業務持續分類和解耦

平臺要分為穩定平臺和創新平臺,穩定平臺承載主要的客戶,創新平臺承載需要頻繁有需求的客戶;要建立持續分類的標準和工具,類似CICD概念能夠在客戶發生變化時快速調整。

  • 架構解耦有清晰的目標

目標清晰具體表現為:各應用獨立發布版本,獨立升級;獨立資源部署,應用之間隔離,不會互相影響穩定性;各應用團隊獨立工作,通過API高效協作。

  • 組件低耦合,呈現緊耦合,表里不一

多應用之間采用低耦合交互原則,應用之間僅通過API接口交互,應用之間做到獨立發布;產品內在的能力組件是低耦合的,產品設計在最終提供給客戶的呈現必須是緊耦合的;表里不一,必須通過優秀的架構師把外在一體的呈現分解和抽象到邊界清晰的模塊內。

3.客戶為中心原則。

  • 灰度原則

平臺灰度原則,所有新版本發布先在創新平臺進行,修復小問題后再升級穩定平臺;客戶灰度原則,對單一客戶提的需求,采用在單一客戶上灰度的方式開發和上線,避免變更影響其他客戶;客戶可在多平臺可移動原則,客戶的穩定需求和創新需求是變動的,需要具備客戶無感遷移方案,周期性動態調整平臺上的客戶,達到平衡作用。

  • 快速回退原則

出現問題判斷是否是單一客戶問題,如果是全局問題,影響一類客戶占比超過10%的,影響大客戶1個以上的,快速回退再分析問題解決問題;需求緊急程度永遠是低于故障緊急程度,確保中午或當天晚上修復問題再次上線。

  • API接口原則

API接口一經發布,不可刪除和變更接口定義和返回,只可以以兼容的方式增加參數和返回;API接口的實現工作量要遠小于業務集成所需,接口的設計一定是架構師主要工作,也是架構思想的體現。

4.大模型重構SaaS技術架構展望

到目前為止,天潤融通以AI為核心,融合了包括接入渠道、營銷服業務場景在內的若干應用。而從今年年初,我們就將2023年定位于用大模型來重構我們聯絡中心架構的元年,在此做一些介紹和展望。

圖片圖片

當前,我們融合ChatGPT、文心一言、通義千問等LLM的能力,上線了語料擴寫、知識抽取、文檔問答引擎等功能,另外,還有話術優化、閑聊寒喧兜底等功能在測試中。

總體而言,大模型對于云聯絡SaaS場景的革新(或影響)將會非常大。客戶對大模型的期望非常高,對我們也有很多期望。當然,也有人會焦慮,當機器大量取代了人工的時候會帶來某些不可測的顛覆式改變。但我們相信,面向客戶的需求,貼近客戶行動的組織是可以轉型成功的,而不是反過來。

五、總結

總結一下今天演講中的重要內容。

  1. 架構設計的理念和原則是SaaS的核心靈魂。
  2. 要平衡平臺穩定和創新之間的矛盾,就要通過業務的分類和解耦。
  3. 構建SaaS業務基礎框架,提高復用效率。
  4. 通過PaaS化架構來構建競爭壁壘。

我相信,優秀的技術架構是演進出來的。這不意味著你要一個個坑重新踩一遍,我已經踩了這么多年的坑,不斷地從坑里爬出來。今天的分享就是為了讓大家少踩一些坑。或者當你準備往下踩的時候,你感覺這是個坑,你可以以開放的心態對外多交流,通過這種交流來加速你對架構的某些理解。

責任編輯:武曉燕 來源: 51CTO技術棧
相關推薦

2023-05-12 07:52:13

架構設計設計原則

2015-10-29 10:50:46

Android架構設計原則

2024-02-26 00:00:00

Nginx服務器HTTP

2021-05-07 15:27:23

架構設計架構開發

2022-07-14 16:35:11

C語言編程語言

2021-11-01 21:01:01

架構設計軟件

2016-02-18 10:09:23

12306核心思路架構

2025-01-15 08:10:29

Java架構代碼

2024-09-09 09:00:12

架構設計算法

2022-04-20 10:15:56

SaaS模塊化客戶

2024-11-22 14:28:00

2023-07-09 15:24:05

架構設計思想AKF

2015-10-16 14:35:05

SaaSCRM架構設計

2021-06-02 06:06:58

設計架構開發

2024-08-16 14:01:00

2022-02-10 23:38:23

API架構設計

2018-08-13 09:09:35

Nginx服務器內部

2019-05-21 21:15:32

架構架構設計性能優化

2025-04-15 04:00:00

2024-09-19 08:46:46

SPIAPI接口
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 99久久久99久久国产片鸭王 | 日本小视频网站 | 99免费精品视频 | 欧美日韩专区 | 99久久国产综合精品麻豆 | 99福利视频导航 | 日韩一区二区三区在线 | 国产一区二区在线视频 | 国产成在线观看免费视频 | 99免费精品视频 | 国产精品高清在线 | 日韩精品在线播放 | 天天干国产 | 亚洲精品黄色 | 懂色av色香蕉一区二区蜜桃 | 狠狠的操 | 欧美日韩一区二区三区四区五区 | 一区二区精品电影 | 黄色一级网 | 国产99久久久国产精品 | 黑人中文字幕一区二区三区 | 久久国产成人 | av入口| 久久精品中文 | 亚洲精品亚洲人成人网 | 国产你懂的在线观看 | 欧美在线视频一区 | 久久69精品久久久久久久电影好 | 成人片免费看 | 欧美日韩中文字幕在线 | 国产激情91久久精品导航 | 羞羞网站在线观看 | 伦理午夜电影免费观看 | 99国内精品| 国产乱码一二三区精品 | 激情小说综合网 | 日本一卡精品视频免费 | 91在线一区 | 国产高清在线精品 | 国产精品观看 | 久久伊人影院 |