MyCat集群;
ZK集群。
圖8 基于Redis的數(shù)據緩存層
另外一個重要組件是數(shù)據緩存，如圖8所示，數(shù)據緩存通常以Redis來實現(xiàn)。Redis也呈現(xiàn)上述MySQL服務類似的特點。
對于上述無論是數(shù)據持久層服務，還是非持久層，從云化角度，都需要完善如下功能：
服務的自擴展/自縮容;
集群服務的自動注冊，無論是擴容還是縮容;
調度規(guī)則;
自動部署、配置、升級;
監(jiān)控、安全、審計;
以應用無感知的形式，在主/從節(jié)點失效(服務實例失效、虛擬機/容器失效、宿主機失效、交換機/電源失效)的服務自動切換。
最后的服務自動切換又至少包括：
服務實例的故障自動感知與實時自動切換;
服務IP的自動漂移，在復雜情況下，至少還包括讀、寫IP等;
整個集群管理關系的穩(wěn)定;
應用的無感知(實際上應該略有感知，但數(shù)據無影響，服務略有遲滯);
硬件更換、維護對于應用無感知;
服務遷移對應用的無感知。
其中，應用無感知的處理是難中之難。當單個服務失效，一般好處理，萬一是多個服務失效呢?
企業(yè)IT應用架構之應用資源的調度
圖9 企業(yè)應用服務的調度
如圖9所示，調度通常應包括以下層次：
Region;
可用域;
集群(OpenStack主機集合);
其他約束條件，如CPU、內存、磁盤、硬件類型等。
然而，事情往往比想象的復雜，如：
有限的物理資源，并不足以保證我們能將應用盡可能分布開;
實際環(huán)境還包括物理機上運行的應用、容器和虛擬機;
用戶在創(chuàng)建完初始環(huán)境之后，還要擴容(調度多次)等;
……
因此，調度并不能按理想行事，許多時候需要折中和遷就，調度邏輯需要將各種復雜的現(xiàn)實情況考慮在內，對每種情況進行演繹，才能得到較為理想的結果 (現(xiàn)實世界中，完美并不存在)。
企業(yè)IT應用架構之敏捷的產品開發(fā)
“老生常談”的產品開發(fā)的痛——如何破，讓老板和工程師都認可?老板希望實現(xiàn)產品開發(fā)價值的最大化，縮短開發(fā)時間，提高開發(fā)效率，但擔心形而上學;工程師需要的是簡單有效，而不是忽悠，繞圈的折磨人，做無用功。
如何立，讓老板和工程師都歡迎?解決現(xiàn)有的開發(fā)難點，不是推倒現(xiàn)有模式重頭開始。老板歡迎引入好的方法論，并帶來商業(yè)利益;工程師歡迎自動化辦法， 合理使用工具，而不是通過工具來玩人。
OpenStack項目帶來的CI/CD的啟示
對零售電商來說，產品的持續(xù)創(chuàng)新及發(fā)布流程是平臺的競爭力。特別在移動端的應用，從移動應用的設計、快速上線、產品運營到可視化管理，需要有自動化測試、敏捷開發(fā)、持續(xù)集成(CI)和持續(xù)交付 (CD)等手段進行高效率支撐。其中，產品開發(fā)設計和集成上線等重要環(huán)節(jié)，對開發(fā)團隊的開發(fā)效率及軟件的功能迭代都有較高要求。基于這些考慮，底層的OpenStack平臺做了大量的實踐優(yōu)化。
■ 移動應用開發(fā)設計：
VM/容器，按需提供
集成開發(fā)環(huán)境(定制鏡像包/軟件包)
內嵌應用開發(fā)市場
■ 移動應用集成測試：
持續(xù)集成(CI)，快速迭代
協(xié)同測試環(huán)境
類生產環(huán)境，灰度發(fā)布
APP客戶端測試環(huán)境
從實踐來看，敏捷開發(fā)的優(yōu)勢是顯而易見的。以某互聯(lián)網消費金融產品為例，通過敏捷開發(fā)實踐彌補項目開發(fā)周期過長、需求變更復雜的弊端，產品需求的反饋周期能從6個月左右縮短至半個月;產品變更的需求，能從1個月縮短至1周。這些都是真實的開發(fā)能力提升。
僅僅有一些方法和工具是不夠的，真正對產品開發(fā)帶來價值，是如何完成產品的敏捷創(chuàng)新、降低風險、并根據市場反饋及時適配產品。但實際情況往往并不如想象中的美好。因為傳統(tǒng)的產品開發(fā)模式中，企業(yè)需 要協(xié)調大量的內部資源，牽涉到跨部門的業(yè)務邏輯、數(shù)據共享服務，往往會有多個部門要配合產品開發(fā)進行協(xié)作和業(yè)務審計。這些對小步迭代、自組織的敏捷開發(fā)來講，是真實的風險所在。