本文由 網易雲 發布。
數字化轉型浪潮之下，采用雲計算服務提升業務敏捷性、降低運維成本，成為了傳統企業的優選方案。網易雲資深解決方案架構師張亮通過某物流企業客戶的實際案例，分享了傳統業務系統在雲上的架構設計如何滿足數據高可靠、業務高可用的需求，並總結了傳統業務上雲的常見問題和解決方案。
物流企業業務系統上雲需求
對於物流企業來說，內部溝通、供應鏈協同對優化供應鏈效率提升核心競爭力非常重要。作為行業翹楚，該物流企業客戶建立了一個企業級移動辦公平台，該平台集成了即時通訊（IM）、企業內部的ERP、OA以及核心供應鏈信息，用於支持內部員工的內部溝通協作，會議、日程安排以及供應鏈信息、ERP信息、OA流程審批和辦理的查詢，平台同時也提供給上下游合作伙伴查詢供應鏈信息，以滿足供應鏈協同的需求。該系統最初部署在客戶自建機房中，服務於客戶內部員工，但為了給一些大型合作伙伴提供類似的能力，客戶同時采用了網易雲支撐系統的建設和運行。
客戶自建機房和網易雲基礎設施存在一些差異，例如客戶自建機房有共享SAN和NAS，並采用帶庫和商業備份軟件來滿足數據合規的要求（存儲冷數據、歸檔），MySQL數據庫運行在物理機上，而網易雲作為成熟的互聯網服務，采並沒有提供共享塊存儲服務，數據庫是運行在虛擬機上的。
由於該系統要作為一項業務給第三方提供服務，項目一期覆蓋數萬名用戶，考慮基礎設施的差異性，客戶最為關注如下四個方面：
數據安全性：影響客戶業務的數據，包括員工通信記錄、日程和供應鏈信息等，必須保證最高的安全性和可靠性；
業務可用性：此業務系統是客戶為其客戶提供的服務，因此對於SLA關注度非常高。客戶要求在極端狀況下（整個生產站點不可用）需要有快速業務恢復能力；
功能：應用探活、監控告警、內網負載均衡（LB）、內網DNS等功能，直接影響客戶的運維能力和部署高可用業務的便捷性；
性能：客戶原有數據庫使用物理機，采用虛擬機擔心性能不足，需要避免高並發場景下會的卡頓甚至崩潰的情況。
網易雲跨機房容災架構方案
客戶原有業務系統底層是一個傳統的同城主備容災雙機房架構（主機房宕機，則備機房接管），在應用側采用了Redis緩存、Kafka、內外網負載均衡，是一個類互聯網架構。系統采用商業硬件全局負載均衡（GSLB）做站點間的容災，后端存儲有傳統的SAN、NAS、磁帶庫和VTL（虛擬磁帶庫）等，持久化數據大部分在存儲上，通過專線和存儲能力做跨站點的快照同步和數據同步復制。一般說來，商業磁盤陣列的高級License會帶這些功能，但高級License比較昂貴，且該方案的容災能力極大依賴於陣列設備的容災能力，一旦陣列設備出故障，數據存儲就危險。此外，Jetty、Java應用間是軟負載均衡的設計，對外有硬件負載均衡。
該業務系統在網易雲上的部署是一個分步試水、逐步完善的過程。業務系統的即時通訊能力由網易雲通信服務（雲信）SDK提供底層能力，客戶自己做上層的封裝，雲信和應用系統部署在不同的機房，通過網易雲內部高速通信。剛開始的架構相對簡單，沒有考慮容災，Redis、Kafka、RDS、NAS都映射原來的系統架構，GSLB取消，用Elasticsearch做日志搜索。
之后是跨機房容災的完善。針對原有系統，運維部門每隔半年會進行一次容災切換的演練，所以客戶希望雲上容災也能滿足數據可靠性、業務可用性的需求。
張亮介紹，雲上跨機房容災根據機房距離和網絡延遲，可以分為兩種：一是跨可用區（AZ）容災，一般用來支持需要雙活的業務；二是跨Region的容災，一般是異地，兩個機房比較遠，網絡延遲無法滿足雙活的要求。網易雲為客戶設計了跨AZ容災的方案。客戶最初在雲主機中自己搭建Redis和Kafka，后來發現需要自己關注監控、高可用，但這是網易雲現成的Redis和Kafka服務自帶的功能。
網易雲提供的容災服務包括：
負載均衡：提供跨機房的負載均衡服務（NLB），每個機房是2個NLB實例（主備），但客戶流量進來只看到同一個公網IP——如果生產站點AZ1宕機，路由會實現IP漂移，把IP關聯到災備站點AZ2上，客戶不需要關注IP的變化。
數據持久化：提供跨機房的RDS高可用實例，生產站點主備2個實例，災備站點1個實例（考慮成本因素），通過內部DNS訪問，一邊的RDS宕機，對於應用來說是無感知的，因為系統會自動把域名解析到災備站點的RDS實例上。
文件系統服務：通過跨機房的復制做數據同步，對於用戶來說，數據持久化不需要管。
Kafka：通過MirrorMaker做跨機房同步，它的消費者可以在災備站點去消費Kafka和消息，如果只是部分服務宕機，系統可以提供跨機房的訪問，當然延遲會比同機房高一些，這取決於應用對訪問數據延遲的要求，如果延遲要求非常高，可能需要做應用單元化，盡量減少跨機房的訪問，把一些對延遲敏感的請求放在一個機房內，這是業務架構上的設計。
張亮補充說，網易雲支持應用去訪問另外一個機房的RDS，但應用之間的容災還需要客戶自己做跨機房部署。NLB可以通過內網DNS判斷請求是從哪個AZ過來的，從而讓應用能夠正確訪問對應的底層服務。
跨Region和跨AZ不一樣，后者在同一個VPC里面，前者在兩個不同的VPC里面，網絡延遲比較高，NLB沒有提供跨機房高可用實例，對外IP不一樣，需要外部有一個類似GSLB或者DNS的服務去做流量切換。其他的如RDS、Kafka的復制，依賴於VPC Peering，需要在核心交換機上做一些后台操作，讓兩個VPC能打通（默認內網是不通的），否則需要通過公網再從前端路由繞回來，無法通過機房內部專線直接訪問。
跨Region的RPO（恢復點目標）比跨AZ要差，跨AZ的RDS可以做到RPO等於0，兩邊都寫入以后，才能返回“寫成功”。而跨Region，一邊寫完就返回“寫成功”，如果數據只是在主站點寫成功，尚未復制到災備站點時主站點宕機，這就會造成數據永久丟失。傳統架構下的Oracle RAC跨機房集群、存儲雙活的方案，其實每一次數據寫入都是雙寫，才能實現雙活。
所以，跨Region容災一般用於兩地三中心的異地災備，業務可用性要求高的情況下，建議客戶采用跨AZ容災的部署架構。對於客戶而言，基於雲的跨AZ容災方案，只是在容災、監控、服務的使用方法上和自建機房有所區別，但滿足RPO和RTO的要求沒有問題。
張亮補充說，跨AZ容災切換是客戶自己做切換，RPO取決於客戶運維團隊多久才能感知故障、多久把災備站點服務配置好，因為客戶應用的配置比較傳統，提前把后端的服務IP、DNS域名寫入配置文件，而不是采用服務注冊/服務發現的機制動態發布。如果進行應用微服務化改造，RTO還可以有很大的提升空間。
上雲常見問題與對策
對於托管IDC、自建機房的傳統行業而言，雲基礎設施帶來的變化確實需要慮周全。基於網易雲支撐傳統業務上雲的經驗，張亮最后總結了傳統業務上雲的常見問題和解決方案。
雲上很少有共享塊存儲。SQL Server提供的Always-On故障轉移集群高可用方案需要共享塊存儲的支撐，但企業現在可以使用無需共享存儲的SQL Server高可用方案，比如日志傳輸、Always-On可用性組等SQL Server 2012及之后的版本都支持的方案，都不依賴於任何共享存儲形式。
VPC網絡不支持廣播、多播，而一些應用需要通過廣播、多播的形式做集群。
Keepalived：升級到支持單播的新版本，在配置文件中指定使用單播，即可在VPC網絡下正常工作。
Tomcat通過廣播支持集群成員通信：一是使用Tomcat-Static cluster membership這種靜態方式，通過在配置文件中手動告知集群節點有哪些成員，彈性伸縮比較麻煩，只適合規模小的業務；二是無狀態化，把Session從Tomcat分出來，放到Redis之類的服務中。
采用N2N Peer-to-Peer VPN的方案，在VPC網絡上再構建一個VPN網絡，就可以廣播，但這種方式會有性能損耗，可以用於POC測試、概念驗證，生產環境慎用。
無物理磁帶庫。一些行業有合規要求，不經常訪問的冷數據會存儲在磁帶庫中。在雲上有兩種方案：一是通過雲服務商提供的VTL存儲網關，備份軟件連接網關，可以把后端當做磁帶庫使用；二是現在不少的備份軟件已經支持主流雲服務商的對象存儲服務，直接在備份軟件中把數據備份到對象存儲，成本比磁盤陣列或者NAS要低很多。
網易雲為您提供對象存儲、負載均衡等服務，感興趣的朋友歡迎點擊免費試用。
了解 網易雲 ：
網易雲官網：https://www.163yun.com/
新用戶大禮包：https://www.163yun.com/gift
網易雲社區：https://sq.163yun.com/