微軟Azure學習總結---電商架構深度解析及架構設計

本週參加了微軟Azure的課程學習，總結以下：

電商架構深度解析及架構設計

    1. 電商的機會分析

 

        初創起步階段：

            雲平臺前期資金的要求低，使用方便，容易擴展，基本上是這部分公司的首選平臺。

            Azure的公網IP資源，帶寬資源和VM資源可以很好的知足他們的技術需求。

            Azure的PaaS服務和CDN服務能夠提供系統平臺的快速搭建。

            若是是跨境電商，Azure雲可以提供更好的國際化服務。

 

        規模化運營階段：

            Azure支持混合部署的能力，能夠快速提供相應的公網帶寬資源，計算資源和服務。好比前臺和中臺的一些應用可部署在Azure上。

            Go global的應用場景。

            Azure豐富的微服務部署能力和DevOps工具。

            Azure inftrastructure as code的能力幫助他們實現自動化。

            大數據和IOT相關的PaaS服務能夠助力業務實現智能化。

 

        穩定發展階段：

            關注新項目，重新系統和新項目着手。

            Go global的項目。

            大批量的並行計算資源。

            系統的混合部署，容災或雙活部署。

            安全開發體系的規範和能力的輸出

            機器學習和AI服務的提供和能力的輸出        

 

    2. 電商系統面臨的挑戰

        資源的彈性變化 ，應用系統的靈活伸縮

        基礎架構的高可用，應用系統的高可用

        系統自動化，業務智能化，大數據運營

        系統和數據的安全性

 

    3. 電商系統主流架構的演進

        升級改造前：

            單體應用

            多個團隊負責，責任不清晰

            代碼複雜，管理性差

            代碼升級複雜，工程量大

            代碼部署成爲瓶頸

            擴展困難

            錯誤排查很困難

        升級改造後：

            微服務

            一個團隊負責分工明確，責任明晰

            易於採用新的技術，快速迭代

            可快速部署

            可單點擴展，靈活高效

            易於自動化

 

    4.雲上應用架構重要原則

 

        假定任何服務均可能失效

            NIC，VM，網絡，應用，系統，區域均可能失效；

            故障注入，主動測試；

 

        面向彈性設計，系統解耦

            橫向擴展能力，充分利用冗餘性無態化改造；

            使用Queue， BlobQueue, Service Bus, Event Hub進行解耦

 

        計算和存儲分離

            構建統一惟一的數據源：Blob服務;

            採用多種數據存儲技術

 

        重視工具和自動化流程

            程序化全部的事情，可編程ARM；

            自動化全部的事情，運維層面，業務層面

 

    5. 服務提供應的開發部署建議

        發佈監控指標，服務的狀態透明化；

        無態化，可橫向擴展；

        支持冪等性操做

        保護本身，實現安全驗證；

        實現高校的流量控制機制；

        對故障進行隔離；

        隱藏服務的實現細節，只暴露簡潔的接口。

        保持向後的兼容性；

        對API進行的版本管理，可以在API升級時及時通知消費者。

 

    6. 服務消費方的開發部署建議

        面向假定失效來設計

        考慮當被限速或截流時的措施

        良好的重試機制，包括帶有數回退機制的重試策略

        優雅的降級，保證核心功能的SLA

        在高峯期要快速的失敗，節約寶貴的系統資源

        儘量的使用緩存來提高性能

        客戶端的負載均衡機制

        

    7. 微服務的服務發現

        基本要求：可使用DNS，而不是IP來命令和訪問服務

        採用動態服務註冊服務

            Etcd：高可用，分佈式的key-value存儲，用來共享配置和服務發現。

            Consul：發現和配置服務的工具，能夠執行監控檢測來實現服務的高可用。

            Zookeeper：經常使用的，爲分佈式應用設計的高可用協調服務。

            Eureka：服務註冊表，提供了REST API的註冊和查詢功能。

 

    8.Azure上部署微服務建議

        管控模式：不一樣的微服務部署在不一樣的資源組下面；同一個資源組只部署一個微服務的多個實例

        部署選項：

            IaaS：VM, Azure AppService，自選機型，服務託管，可自動伸縮 

            PaaS：Container Service，Azure Service Fabric, 模板化管理，自動編排調度，秒級部署

            SaaS：Azure Fuctions(國內暫未上線)，API Management，徹底託管,自動伸縮，秒級部署

        VM/APP服務/容器：

            每一個VM/APP服務/容器部署一個服務

                獨立的管理，管理權限明確；獨立擴展；獨立部署；獨立升級；可支持不可變的部署方式

        API management：

            使用API management來做爲微服務對外的出口，特性：安全驗證、流量控制、數據緩存、版本管理、性能監控、事件日誌、混合部署。

        基於VM的部署建議

            每一個微服務可部署在一個resource group中，全部資源保持同一輩子命週期；

            每一個微服務能夠考慮採用單獨的負載均衡服務。

            每一個微服務的Tier部署在單獨的可用性集中，這樣能夠保證每一個Tier的可用性；

            建議使用每一個微服務採用單獨的存儲帳號，若是使用Unmanaged Disk應該考慮20000IOPS的容量單元

            對外的部署部署在Public的子網，其它的部署在Private子網

            可考慮NSG等安全措施的部署

 

    9. Azure相關負載均衡器說明

        Azure Load Balancer：四層的負載均衡器，對於微服務部署在VM、Service Fabric、 ACS中的場景，可提供基於IP和端口的負載均衡功能。

        Azure Application Gateway：七層的負載均衡器，可提供基於URL Path模式的流量負載均衡模式，能夠和Azure Load Balancer配合使用，ALB後端，構建二級的負載均衡系統。

        Azure Web Apps: Azure Web App自己已經爲微服務提供了負載均衡的功能。另外，也能夠用採用內置的ARP配置基於URL Path的反向代理。

        Azure Service Fabric：Service Fabric已經對部署在其上的微服務提供了基於IP和端口的負載均衡能力，若是不一樣的服務需求監聽同一個端口，好比80端口須要服務兩個不一樣的服務IP:80/cart和IP:80/order，可使用OWIN Listener來實現這個功能。

        ACS：對於DC/OS，默認已經配置了Azure Load Balancer，同時也能夠配置其自有的Marathon Load Balancer進行集羣內部的負載均衡，對於Kuberenetes，因爲在集羣內部已經使用了Kube-proxy做爲service的負載均衡組件，能夠將服務類型配置爲LoadBalancer，從而將Azure Load Balancer做爲外部的負載均衡器。

 

    10. 微服務架構問題以及措施

        雪崩效應

            現象：微服務之間相互依賴，服務鏈中單個服務因爲出現各類緣由致使請求響應慢，隨着響應請求的累積形成該服務不可用，進而影響整個系統，形成大面積的服務不可用現象。

            措施：

                超時機制，避免超時請求佔用系統資源

                熔斷機制，產生大量未能正常處理的請求，則能夠熔斷該服務的調用，快速釋放資源

                隔離機制，物理隔離、線程隔離來對服務進行隔離，避免相互之間的干擾

 

        IO放大問題

            現象：因爲微服務之間相互依賴，一個請求可能會依賴一條服務鏈，前端等待一條請求可能在後端成倍的放大。

            措施：

                客戶端緩衝(緩存）

 

        熱點問題：

            現象：在處理一個請求的過程當中，可能須要調用幾個相應的微服務，而這些微服務有可能同時依賴某一公共服務，這樣就會致使這個公共服務成爲熱點，成爲系統的瓶頸。

            措施：在向下遊請求時，攜帶必要的信息，使整個請求連接只有第一次依賴會去請求公共服務。

 

        日誌追蹤問題：

            現象：在處理一個請求的過程當中，可能須要調用幾個相關的微服務，日誌記錄很分散，若是出現問題，很難進行全鏈路的追蹤和定位。

            措施：針對每次請求建立全鏈路的惟一ID，實現方式有：zipkin與dapper

 

    11.微服務的解耦模式

        消息隊列:Azure Service Bus 保證順序，至多一次，至少一次；Azure Service Bus可在分區的基礎上保證消息的順序，支持事務性消息，重複消息檢測，能夠簡化實現過程。

 

    12.微服務之間事務管理和數據一致性

        典型方案：二階段提交，強一致性方案，經過事務性消息來確保事務。

        簡化版方案：將須要跨微服務同步的數據庫放在一個實例中，增長一個存放消息的庫。利用數據庫的XA Transactions的支持進行跨庫的事務處理。僅適合數據庫操做場景，不適合RPC操做場景。

        方案三：經過DDD的Event Sourcing和CQRS來解決，經過一個業務用例對應一個事務，一個事務對應一個聚合根，也即在一次事務中，只能對一個聚合根進行操做。

        

    13. 微服務和Azure的組合優點

        資源按需供應，熱點資源可動態擴展

        基礎架構即代碼，結合資源組可進行全生命週期管理

        系統之間依賴性低，可擴展性和可用性較高

        可用Server-less架構

 

    14.電商秒殺系統參考架構

        秒殺系統實際是限流系統，攔截低質量的流量，將高質量的流量放入到後臺處理

 

        主要模塊：

            Gate Keeper：接受客戶請求，將用戶請求發送到後端作相應的處理，並將結果反饋給用戶端

            Safe Protector：防刷服務，過濾IP和客戶ID。可實現準時處理，動態增長黑名單

            Policy Controller：業務規則過濾，例如能夠根據用戶級別和商品編號對可購買的商品種類和數量進行限制。

            Inventory Manager：管理秒殺環節的庫存狀況，一般庫存都是在秒殺開始之間單獨導入用於秒殺的商品和庫存。

            Shooping Cart：將商品將入購物車，經過Safe Protector， Policy Controller和Inventory Manager驗證的用戶請求將會成功的將商品加入購物車

 

        Safe Protector 實現動態防刷：

            數據獲取：Gate Keeper將日誌打入Azure Event Hubs

            數據處理：由Azure Stream Analytics或storm從Event Hubs讀取數據，並寫入Azure HDInSight進行計算處理。

            黑名單的動態加入：有單獨的worker進程將HDInsight計算的新的黑名單加入Safe Protector的緩存數據庫中。

            新的請求校驗：新的請求將會按照更後的黑名單庫進行驗證。

        

        爲何Azure Redis會適合這個場景？

            Redis的key有失效時間設定，與超時不下單自動清空購物車場景契合。

            Redis支持Hashes的數據格式，支持商品的快速存讀；且商品之間的數據schema能夠徹底不一樣，對應商品的不一樣特性。

            防刷服務中須要統計快速有效的Unique ID/UID的訪問次數，可採用Redis的Sorted set來快速實現。

            Azure Redis是託管的PaaS服務，易於擴展，可實現集羣部署，自動分片，可實現跨區域複製。

 

        爲何Azure DocumentDB適合這個場景？

            Document DB支持不一樣的一致性級別（能夠細化到每一個查詢）和服務器端的事務處理，能夠適用於許多場景。

            不一樣商品不一樣品類的屬性是徹底不同的，屬性的數量和名稱多是徹底不同的，傳統的數據庫方式會存在性能、擴展、靈活性上的問題。 Document DB支持Schema less方式。很好的支持EAV模式，能夠經過內置的Json數據結構簡單高效的解決該問題。

            爆款商品的數據操做，會對爆款商品的數據所在分區成爲熱點和瓶頸，影響系統總體性能。Document DB能夠經過合理的設置partition key，將產品的數據拷貝合理的分散到多個shard，從而消除熱點。

            Document DB有很是強大的索引功能，能夠自動建立基於JSON內容的索引，能夠根據不一樣的商品屬性實現人性化的搜索與過濾。

            Document DB讀寫性很好，P99的單獨的讀操做的響應時間在10ms以內，並且性能是可配置和可擴展的。

 

        

    15. 電商系統的首頁展現架構

        CDN + Load Balancer + Azure Storage Blobs + 頁面更新服務 + 數據更新服務

 

    16. 電商離線推薦系統參考

        日誌數據：

            flume, logstasjh, fluentd進行日誌收集，頻率基於分鐘或者小時，直接存儲到azure Blob Storage.

            Azure Blob storage 可做爲惟一的全量數據的核心存儲源，實現計算和存儲的分離。實現HDInsightr Hadoop集羣的單獨自由的伸縮，升級和維護。

            Azure Blob storage 和Hadoop深度集成，在Hadoop集羣中使用「WASB://」便可直接訪問Azure Blob Storage，和訪問HDFS同樣方便。

            Azure Blob storage支持Append Blob，參考工具：blobfs

         結構化數據：

            可採用Sqoop進行數據的抽取，數據可存儲在Hbase，Hive或SQL中。

        推薦系統的目標：

            推薦系統是電商精細化運營的核心平臺，是實現千人千面的基礎，推薦系統是最終目標就是提高流量 的轉化率。

        推薦系統的技術特色：

            推薦算法的有效性要求高

            實時性要求高，通常要求在1秒內完成推薦

            系統複雜，涉及從數據攝入到展示的各個環節

        推薦算法：

            主要有Content-Basesd Filtering 和Collaborative Filtering。在電商中主流的推薦算法都是在Collaborative Filtering的基礎上作的改進和優化。 Collaborative Filtering有兩種方法：User-Based和Item-based

 

 

2、Azure網絡實驗

        這部分主要是根據操做手冊來對Azure的網絡配置進行操做，操做手冊在附件中， 主要有八個實驗，這裏總結一下實驗中的一些基本概念：

        1.Azure VNET

            Azure 資源能夠經過 Azure 虛擬網絡服務與虛擬網絡中的其餘資源安全地通訊。 虛擬網絡是你本身的網絡在雲中的表現形式。 虛擬網絡是對專用於訂閱的 Azure 雲進行的邏輯隔離。 可將虛擬網絡鏈接到其餘虛擬網絡，或本地網絡。

 

        2.Azure NSG

            網絡安全組 (NSG) 包含一系列安全規則，這些規則能夠容許或拒絕流向鏈接到 Azure 虛擬網絡 (VNet) 的資源的網絡流量。 能夠將 NSG 關聯到子網、單個 VM（經典）或附加到 VM 的單個網絡接口 (NIC) (Resource Manager)。 將 NSG 關聯到子網時，規則適用於鏈接到該子網的全部資源。 也可經過將 NSG 關聯到 VM 或 NIC 來進一步限制流量。

 

        3.Azure Load Balancer

            Azure 負載均衡器可提升應用程序的可用性和網絡性能。 它是第 4 層（TCP、UDP）類型的負載均衡器，可在負載均衡集中定義的運行情況良好的服務實例之間分配傳入流量。

            Azure 負載均衡器使用基於哈希的分發算法。 默認狀況下，它使用 5 元組哈希（包括源 IP、源端口、目標 IP、目標端口和協議類型）將流量映射到可用服務器。

            

        4.Azure NAT

           配置負載均衡器中的端口轉發功能來實現NAT功能。

 

        5.Azure VNET GW

           要跨虛擬網絡，須要配置點到站點虛擬專用網。

            

        6.Azure VNET Peering

            使用虛擬網絡對等互連能夠無縫鏈接兩個 Azure 虛擬網絡。 創建對等互連後，出於鏈接目的，兩個虛擬網絡會顯示爲一個。 對等虛擬網絡中虛擬機之間的流量經過 Microsoft 主幹基礎結構路由，很是相似於只經過專用 IP 地址在同一虛擬網絡中的虛擬機之間路由流量。      

 

        7.Azure NVA + UDR

            能夠在 Azure 中建立自定義或用戶定義路由，以便替代 Azure 的默認系統路由，或者向子網的路由表添加其餘路由。 能夠在 Azure 中建立一個路由表，而後將該路由表關聯到零個或零個以上的虛擬網絡子網。 每一個子網能夠有一個與之關聯的路由表，也能夠沒有。 若是建立一個路由表並將其關聯到子網，則其中的路由會與 Azure 默認狀況下添加到子網的默認路由組合在一塊兒，或者將其替代。

 

        8.Azure ExpressGW

            專線鏈接。