系統中的非功能性需求
今天我們的主題是當當高可用架構設計之道，高可用并不是功能性的需求，而是傳統的IT當中非功能性需求的一部分。大家可以看到我這里羅列了很多非功能性需求，但是這當中并沒有「高可用」這三個字。
舉一個例子，比如說你買了一臺蘋果手機，無論是作為手機還是電腦，還是MP3，還是專門用來看視頻的，都是功能；那么非功能性呢，比如說大家很崇拜喬布斯，產品設計極致體驗，蘋果手機只有1個鍵，簡單好用，這就是一個非功能性需求。另外還有很多朋友買土豪金的手機，就是為了區分開，因為顏色不一樣。這個顏色也是非功能性需求。
我們簡單介紹幾個非功能性需求。
擴展性，有一些類似的可以抽象成統一模型的東西，如果說做好的話就可以支持擴展。用一個以前的例子，我以前是做電信行業的，比如說有一個需求要在全球通上開一個5塊錢的套餐，接著又要在動感地帶開一個10塊錢的套餐，那么我們就可以做成一個模型，做成一個套餐的產品，品牌是一個屬性，價格也是一個屬性。這樣的話，神州行再來一個50塊錢的套餐，我們就不需要改什么應用，增加一些配置，定義一些產品屬性就可以了，這就是擴展性。
高效率是說你對現有的資源使用是不是足夠高效。比如說有的人寫的代碼比較爛，一啟動就百分之幾十的CPU使用率，這就不太合理。
可測試，很多開發的同學不當回事，覺得開發好功能邏輯就夠了。但是你做出來的東西是要保證質量的。開個玩笑，如果說測試的妹子很漂亮，你愿意手把手的教她如何來測試功能，但要是妹子走了，來了一個糙爺們還需要你還手把手的教，你就不愿意了。因此必須要有一個測試的完整方法、功能說明、測試用例。
這些非功能性的需求，是整個系統是不是正常穩定、可靠運轉，以及被一個團隊長期沿用下去的一個前提。
而可用性，涉及到很多方面。比如說伸縮性，是否能夠在業務量增長的前提之下，通過水平擴展可以很容易支撐更多的業務。比如說安全性、可靠性，數據會不會丟失？所以這里面很多的點，最終都是決定了可用性。
那么可用性是什么呢？可用性就是這套系統最終是給用戶用的，是有這些功能的，但是其他方面如果不能保障好，不能N個用戶一直用，那你這個系統就無法體現它的價值。這是非常重要的，很多剛剛工作幾年的，或者是一直在做產品研發的同學，對這方面沒有切身的體會，沒有在大晚上被人打電話說出了什么問題你趕緊來處理一下，沒有這樣切身的痛苦的體會。
「高可用」到底是什么
接下來我們說一下什么是高可用。CAP理論是指在分布式數據的場景來形容三者不可兼得，就是一致性、可用性和分區容忍性。在整個系統層面也可以這么理解，因為多數系統的核心就是數據，數據本身受限于這三個特性只能滿足兩個，不能三個一起滿足，整個系統也是如此。
在互聯網場景里，因為數據量大分區容忍性是必須要支持的。一致性可以稍微容忍一些，但是可用性是一定要保證的。所以最后多數的互聯網公司多數的業務系統就是犧牲一致性，保證可用性和分區容忍性。
我們繼續往下看，什么可以影響可用性。
首先是天災，去年杭州發生了一起「慘案」，支付寶機房的光纜被挖掘機挖斷了，這就算是一種天災了。還有青云的廣州機房被雷劈了，這也是一種天災。以上的情況基本上是不可抗的。
其次是人禍，攜程公司去年也發生了「慘案」，系統宕機一下午，一直到晚上才恢復；還有阿里云，去年上了一個云盾的功能，用戶在執行可執行文件的時候，就把這個可執行文件給刪了，回頭用戶再找這個可執行文件的時候就找不到了。還有是BUG，在某一些特定場景下系統出問題，這是很正常的。
設計缺陷是要重點說的，它比BUG更宏觀一些，是結構上的問題，不是說你增加幾個判斷，改一下代碼就可以解決的。基本上是屬于一旦發現了，要么就是大改，要么就是重構，調整原來的設計，很難馬上去解決。
至于說性能瓶頸和資源不足，大家知道就是這么多的服務器，如果代碼性能寫得好，可能能扛住更多請求，如果寫得差，可能稍微增長一些就不行了。
性能瓶頸就是短板，比如說負責某個模塊是一個沒有什么經驗的小同學，代碼質量不太高，他就可能成為了整個系統的短板，這個模塊出了問題，其他的代碼寫得再好，整個系統還是不能用。
最后還有一些未知的情況。大家做技術做的時間長會遇到很多無法解釋的「未解之謎」，我們一般稱之為「靈異事件」，這個是指經常發生的，你不知道問題在哪里，但是過段時間就來一次，就好象冥冥之中有人玩你一樣，但是總歸是可以找到原因解決的。
至于說黑天鵝的事件，則是以前從來沒有出現過的情況，突然出現了，讓你不知道應該怎么辦，而且可能是一兩年才出現一次，你會要考慮值不值得找它如何出現的。
還有一些以后就再也不出現了，誰也不知道是怎么回事，你就不知道怎么辦了。最后一個是未知的，我們不知道會出現什么樣的事情，出現的情況我們也不知道如何應對�？茖W告訴我們，已知的我們可以去努力解決，但是未知的，我們無法判斷。
關于系統故障，有一個海因法則，意思是說出現一起嚴重的事故，都是由很多的隱患，很多的小問題，或者說一些問題沒有暴露出來，最終引發特別大的事故。負責運維的同學都知道，公司對系統的可用性是有指標的，是99.9%還是99.99%，還是99.999%，如果說公司沒有這個東西壓著你作為KPI，那就太幸運了，出了問題不至于讓你拿不到獎金。如果說你的公司有，我希望研發和架構的同學都要清楚，而不是只有運維的同學知道，否則就是公司管理不到位，舉個例子如果可用性標準是99.99%，一年系統可以掛的時間是53分鐘，99.999%則是5分鐘，大家想想就知道，攜程掛了一下午，整個可用指標就完不成了，KPI就完成不了。
高可用同時是一個概率的問題。一個復雜的系統，比如說很多模塊或者子系統組成的系統，是可以通過一些方式大概去估算的。前些年云計算很火，很多人都說我們有一個云要自動運行，幾萬臺服務器必須要有自動恢復的系統，最好是分鐘級恢復，秒級恢復。這些都是一個概率，怎么去算呢？比如說我有兩個手機，最近一個月內有3次差一點丟1臺手機，這是未遂事件，那么基本上我丟失的概率就確定了，比如說是1/30。我有兩個手機的話有什么好處，沒有手機用的概率就是1/900。但是丟手機的概率增加了，我就要做好心理準備，沒準哪天就會失去一個。
多數系統是幾臺或者是幾十臺服務器組成一個小的集群，還有很多跟它平行和上下依賴的系統。這種系統都可以用這種方式去算，大概是什么樣的概率。
這個還涉及到容量評估，要考慮系統負載是多少？比如說像我們以前做企業級系統用小型機，小型機的可靠性非常高，平時就是50%左右的負載，這個時候三四臺機器加在一起就夠用了，因為掛一臺基本上系統不會有太大影響。但是如果用不太可靠的PC服務器或者其他解決方式，因為擔心可能出現的狀況，所以現在很多互聯網公司采取的是常年運行10%的CPU或者是20%的CPU狀態。
我們可以考慮一個系統，比如說一臺機器掛了，影響系統部分出現問題的概率有多高，多個系統總有一天會出問題，如果說系統足夠大，大家可以想像，無論是Facebook、谷歌，還是BAT基本上每天都會有各種各樣的小問題。所以越復雜的系統越是難以評估，我們要保證出現問題的時候可控。高可用并不是萬無一失，我們是用更多出問題的概率去降低整個系統出問題的概率。
還有一個說法叫墨菲定律�；旧夏阆氲降淖顗牡氖虑樗倳l生的。上學的時候，數學老師會說，小概率事件基本上不會發生。但是在IT，在一個復雜環境當中，在上千臺上萬臺服務器的集群中，幾百人幾千人做的系統，一定會有一天出問題的。所以人算不如天算，你算出來概率很低，你保證我出問題的概率哪怕是幾十萬分之一，你覺得這輩子就趕不上了？不見得的。
那么怎么辦？就是時刻準備著。這是我做了這么多年開發最大的體會。我們做的是一個7×24小時對外服務的系統，不能停。不能停的概念不是說像有的公司那樣，白天有人用，晚上沒人用，晚上出事了，我們來得及修補修補。但是像電商是7×24小時的，半夜三四點都有下單的。人家在熬夜開心下單的時候，你出了問題，阻止人家的下單，要不然就是打電話投訴，要不然是找地方吐槽。
系統故障不僅是技術上的問題，最嚴重的是影響客戶體驗，前一段時間我們的評論系統出了點小問題：一個客戶買了一個面條機，反饋說并不是因為產品本身做不好面條要退貨，因為其他原因，這個因為產品已經用過了所以按照規定是不能夠退貨的。結果用戶想評論的時候評論不了，用戶就覺得說當點擊評論按鈕時，系統告知接口錯誤，覺得這是在針對他，其實這只是系統故障，但是用戶并不會這么想。
當你做了各種各樣的準備，覺得萬無一失了，難免有一天可能還是會翻船了。但是遇到這樣的事情也是好事，經驗都是在這個時候積累起來的。那么什么是高可用？基本上就是三句話，降低故障出現的概率；縮小故障影響的范圍；出現故障快速恢復。不能因為是個小問題就覺得無所謂，反正我一堆的服務器，掛一個就掛一個吧，這種情況不好說會不會另外一個也掛了。因此有問題要盡快處理，最終的目的就是讓用戶可以正常的使用。
如何設計高可用架構
高可用架構設計常用的「姿勢」。大家看到這是一架飛機。我們有一個比喻說做運維這種系統，就是開著飛機修飛機。首先系統一直運行，其次運營、產品各種業務部門會不停提各種各樣需求，然后領導也許不懂技術，不懂什么叫分支、什么叫循環、什么叫面向對象；但是懂兩個詞，一個是敏捷，一個是迭代。
所以做這件事情的時候難度是比較高的。我們不能讓這架飛機停下來歇幾天，把翅膀換了再飛上去；而是常年在天上飛的，飛上去的時候也許就是個阿帕奇直升機，特別是創業公司�；仡^要拓展一個業務，增加一些功能，做著做著原來的業務不行了，新的業務變成了主營業務，結果變成了F15，從直升機變成了戰斗機，然后變成F16，變成F22。一旦技術團隊沒有做好，一頭栽下去，技術團隊的名聲就砸了。要么是沒做出來，要么是做出來之后一上線掛了，市場費用都白花了，這個責任要技術來承擔。
我在四個領域里面分別提煉了幾條高可用相關的架構方式。
業務架構就是指產品是什么功能，有什么要求。
- 首先是領域切分，不要把雞蛋放在一個籃子里，比如說一些傳統網站，有非常多的二級域名。某一個二級域名掛了，都是不同的服務器，其他的還可以提供正常的服務。
- 系統分級，哪些系統對用戶來說比較重要，級別就會更高，我們就要花更多心思去保障，其他的相對差一些。
- 降低耦合，最近在架構圈當中流行一個詞叫康威定律（編者注：Conway’s law： Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations），是指系統架構是和公司組織架構是有關系的。降低耦合也是如此，不要把系統搞得太復雜，你的組織和團隊不要和太多的部門打交道。優化架構，讓系統的關系盡可能的簡單、明確。這樣出現問題范圍可控。
- 有損服務是什么意思呢？可以犧牲一些用戶體驗來保證基本功能的可用。
系統架構當中，分以下幾點。
- 第一個是數據獨立，不允許跨系統訪問數據庫這個常識大家都懂，但是很多公司做不好，因為沒有強有力的措施去控制。這種事情做起來不太容易，需要管理或者說大家認可才行，但是實際上是非常關鍵的，因為數據如果不切分，系統很難切分，耦合就非常嚴重。時間長了出了問題，你連誰寫的，誰改的這個數據都不知道，那怎么辦？
- 第二點是集群分布，這個就不提了。
- 第三個是冗余部署。比如說電商業務是有波動的，每天的上午11點或者是下午4、5點訂單量都會增長，上班族都要休息一下，給自己的辛苦找一些心理安慰，這個時候開始購物。但不能說就這點增長就彈性部署一次。所以一定要有冗余，一般來講是3-5倍，保證哪怕突然來了一波流量你也可以扛得住。
- 尤其是電商公司，可能會搞一些促銷，可能有的業務部門搞促銷的時候，沒有知會技術部門，覺得這個促銷沒什么，可能一兩天就搞定了，然后流量預估也就上來200%。但是萬一趕上這是網絡紅人、明星或者是小鮮肉出了書、發了唱片或者穿了什么衣服，一下子成了爆款，系統沒扛住，然后運營回頭就得抱怨白折騰了。
- 第四個讀寫分離這個不用說了。
技術架構方面，仔細說一下。要是小公司出了什么問題，幾個人碰個頭，達成共識就可以了；但是一個上規模的公司，技術團隊幾百人甚至是上千人的團隊，如果技術層面控制不了的話，就會有非常嚴重的隱患。
- 首先是選擇使用的技術平臺，有的公司java也有、PHP也有、Python、Go等等的什么都有。
- 其次是人員職能，有的公司說我們的工程師都要做全棧工程師，我們的工程師什么都會。創業團隊可以，但是一般成熟的公司都是專業分工，專業分工就來了一個問題，大家畢竟要對接，而且很多東西需要有人持續運維，因此就有必要統一技術標準。
- 第三點就是規范標準，比如說代碼、發布的規范都要有。如果說可以沉淀的話，以上說的規范是可以做成一個統一的框架，現在當當也在做一個框架。
- 還有就是合理的選型，一方面不同特性的技術需要用到合適的場景當中。另一方面不合適的技術選型一定要盡量堵住。因為現在很多同學都有非常高漲的學習熱情，新技術層出不窮。這樣的話很多人會犯一個「錘子心理」的錯誤。
- 比如說我最近在當當上買了一本書，花了兩個月看完，然后趕上做一個項目，我就覺得自己很懂了，英雄有了用武之地。錘子心理是什么意思呢？他有了一個錘子，看誰都是釘子，就想敲敲。這種情況是要控制的。
- 也許這個技術不是不能用，但是不是增加系統的負擔，公司能不能持續運營。比如招來一個牛人，這個牛人自己寫了一個框架，用了什么算法。用起來確實很好，但是過后牛人走了怎么辦？出了問題怎么辦？誰管？這種問題都是要考慮的。
- 還有就是持續集成。我們要從技術層面去保證多數測試都可以覆蓋到，不能說換一個測試或者是換一個開發就經常犯一些重復的低級錯誤。
基礎架構
- 在一個完整的系統當中有一些和業務沒有關系的系統，比如運維平臺的存在，是為了降低運維的風險，同時也是為了提高效率，保證質量。
- 比如統一監控，那么大一個系統誰知道哪里有問題，哪里不正常，所以必須要統一監控。
- 還有是壓測工具，比如雙十一，你有沒有信心？誰敢說？我們要進行測試，壓測之后我們說5倍沒問題，10倍沒問題。但是不壓測誰敢說？
- 還有就是流量控制。常見是分流和限流，如果說有一個頁面訪問量太大，可以分到類似的頁面去，更大的時候我們只能限流。
電商系統架構
這個圖是一個比較簡單的電商系統架構，主要說說系統分層。最上面的點是展示，包括首頁、搜索、列表、活動專題頁這些東西，這個展示其實都是用戶查詢的，沒有操作，只要用戶可以看就可以了，這些數據是可以緩存，可以靜態化的，可以通過這樣的方式保證用戶訪問，可以把數據都緩存起來。比如說當當的首頁，是不依賴任何系統的，其他系統都掛了，首頁打開是沒有問題的，畢竟主站是最大的流量入口。
還有第二點就是交易系統。和訂單系統是上下游的關系，交易系統是生成訂單的，訂單系統是處理訂單的。交易系統的訂單數據是存在自己的數據庫當中。為什么呢？因為好不容易用戶來了，終于下單了，一定要留住。訂單系統也很復雜，不能說因為訂單系統掛了，導致訂單無法生成了。所以生成訂單這件事情是在交易系統完成的。訂單系統可以異步去處理訂單，訂單系統出了問題，用戶該買還是可以買的，這是電商當中非常重要的。
第三個是商品數據中心，就是為了應對前面的這一堆面向用戶的訪問，我們的數據是單獨有一份只讀的對外提供，和后面的PIM系統是分開的。PIM是寫，這邊是讀。如果PIM掛了，沒有問題。后臺系統不會對前臺造成太大的影響。
交易系統是最核心的，最大的使命是生成訂單。除了基本的生成訂單的功能，還可以做什么呢？第一就是要快！比如說促銷，這里沒有寫價格和庫存，價格和庫存都是敏感數據，要求盡可能準確的，我們都是實時的。但是促銷是可以緩存的，因為現在還不是系統智能去調整促銷策略的，都是靠人工設置的，節奏和頻率都是比較低的，緩存下來之后，基本上是OK的。避免促銷服務不穩定對交易產生影響，如果用戶點半天沒有反應，用戶就會走的，要降低依賴。
還有一個交易單緩存，就是訂單生成之前的臨時數據，要選擇支付方式、要寫地址、要選擇是不是用紅包、抵用券、優惠卡這些東西，選得差不多了，萬一客戶端瀏覽器崩潰了、網斷了或者是閃斷、交易系統應用服務器某一個節點掛了，怎么辦？這是最重要的時刻，都已經臨門一腳了，我們是有緩存的，數據量也不是很大，只要他在比較短的時間內打開，填的東西還在，還可以順暢的往下走。這個也是非常重要的。我記得以前有的網站出了問題，要重新選一遍，那個時候覺得非常郁悶，除非這個東西非常需要，否則那就算了。
電商數據模型
這是電商最常見的數據模型，商家來發布商品、設置促銷、價格、庫存這些東西。用戶來瀏覽、收藏、加入購物車，最后下單。對于平臺電商來說，就會出現多個商家，商品要按照商家來分，訂單也要按照商家來分。但是對用戶來說，收藏、加購物車的商品還有訂單對應的是多個商家。
這個時候有一個非常明確的問題，比如查詢收藏列表，或者是商家管理他的商品的時候，怎么樣可以很快的處理？商品可能有幾千萬上億，肯定不會放在一個數據庫里，多個數據庫，按什么分？后邊按商家分，前邊按用戶分，中間兩套數據庫。
說起來邏輯其實挺簡單，但是很多創業公司沒有琢磨過這個事，中間就是一個庫，上面設一個索引，數據量小還沒有問題，一旦大了怎么辦？覺得這是解決不了的問題。
進一步來說，這只是一個場景，還有一些更具體的場景。比如說我們剛剛提到購物車或者是收藏夾，如果在購物車或者是收藏夾，商品數據不按照用戶來分，也不按照商家分，就按照商品ID來分，均勻的分布在我們的數據層是不是可行？
這個邏輯在平時也許沒有問題，但是電商有一個說法叫爆品，大家可以想像一下，平時是沒有問題的，正常下單正常瀏覽，一旦出現爆品，就會出現熱點數據。爆品所在的數據分片會被用戶集中瀏覽，熱點問題沒有辦法解決就是設計缺陷。再怎么分，那一個商品就在一個庫當中，你也不能把它一劈兩半。就是我剛剛說的，可能突然爆發一下，時間也不長，但是你扛不住，扛不住怎么辦？我們一會兒再說。
資源隔離重點保障，這也是很重要的。比如商品數據中心給前臺提供商品數據，是分成三個集群的。那邊的是網站，這邊是App，這邊是購物車和交易，各自都有自己的緩存和數據庫，數據完全一樣的。為什么要分開？和剛剛說的一樣，首先交易下單是最關鍵的而且性能要保證，不能受到其他場景的影響。其次移動端也非常重要，大家都是在手機上操作，其實對速度是非常關注的，不能因為網站流量大了，導致手機瀏覽緩慢，甚至可以掛掉一個集群，其他的還正常，其實就是不要把雞蛋放到一個籃子里。用空間換時間，用時間換空間。
通過框架來樹立開發規范
我們做的一個框架叫ddframe，這是我們技術層面想做的事情。很多的互聯網公司開發平均工作經驗有3年就不錯了。因為這幾年各種創業公司比較多，膨脹的也很厲害，要找一些有經驗的工程師很難。很多開發同學沒有經歷過各種慘痛教訓，開發都是比較隨意的，因此我們需要做一個開發的框架去給他們做一些規范的事，能夠有效的去幫助他們，盡量不去做一些出格的事情，因此我們做了ddframe。
框架有幾個模塊：包括最核心的部分、包括和監控的對接、SOA的部分DubboX、還有作業框架elastic-job、以及分布式數據庫中間件sharding-JDBC。
Dubbox是我們在Dubbo的層面做了二次開發，現在有不少公司在用，這個部分把一般的服務注冊、軟負載、路由都搞定了。
elastic-job是分布式作業調度框架。采用分布式作業調度框架前有什么問題呢？第一個是怎么實現避免單點，很多人是這樣做的，兩臺機器都部署，其中一臺crontab注釋一下，一臺機器出問題了，就去另外那臺機器上把注釋去掉，這是非常低效的，而且是完全靠人的。機器多了怎么辦？因此我們需要分布式的作業調度。這是我們去年開發的，最近唯品會在我們的早期版本基礎上，自己做了一個內部的作業調度平臺，當然也歡迎大家使用。我們為什么自己做，為什么不用TBSchedule，是因為我們發現沒有特別合適的，所以自己做。
第二個模塊就是RDB，就是分布式數據庫問題，和高可用關系不太大，不詳細介紹�？傮w而言，我們是想通過統一的框架、技術組件降低開發人員實現的復雜度，減少風險，不給他們找麻煩。
有了框架就有了工具，有了工具就有了共同的語言。大家可以回想一下歷史課，秦始皇統一六國之后做了什么，統一度量衡、錢幣、文字。有了這些統一的東西，大家互相之間比較容易交流、積累經驗，如果說某個團隊比較閑了，也可以支持別的團隊，有人在某個團隊膩了，可以去其他的團隊。
運維與監控
原來我們有一個運維平臺，但是去年技術圈出現了那么多的各種事件，運維經理說運維太重要也太危險了，因此我們做了一個強制的生產環境灰度發布，不允許你一鍵發布，給大家一個緩沖。自動備份也是非常重要的，如果說你發現灰度發布第一個節點就報錯了，你要做的事情就是回滾。
接下來是監控。監控是一個很大的系統，非常的重要。一個好的監控系統可能更牛，因為就算是24小時都有運維的同學，但是運維同學也有打盹的時候，或者是沒注意。經常我們會在電影當中看到，某一個大盜進入到某一個大廈當中，保安就在那里喝個茶什么的，保安沒看到。這種事情是經常會有的。
而且有了監控就有了數據，監控不一定觸發報警，但是你有了數據之后可以看趨勢。比如說最重要的一點–預算。我們今年要采購多少臺服務器，多數是拍腦袋拍出來的，業務說我們今年業務量增加30%，我們多采購30%的服務器，就是這么拍腦袋拍出來的，其實這個是不準確的。
如果系統在某些場景下有嚴重的性能衰竭，需要去評估，或者要去看，不同的業務模式會對系統造成不同的壓力。比如有的系統今年負載反而下降了，就往下減服務器。有的可能增加200%，原來10%的負載，現在變成了30%了，那么這種，哪怕你的業務增長30%，這個壓力還是增長200%。這是什么概念？之前是10%到30%，現在就是30%到90%了。你只有有了這些數據，才可以合理的去估算。
大促或者出現爆品時怎么辦
相信在上海的同學也都遇到過這樣的情況。在地鐵站，高峰時限流，用欄桿把人擋住。限流基本上是電商標配，以前沒有，所以動不動就掛了。現在成熟了，如果出現了爆品，出現了熱點數據怎么辦？
你不能說流量一來你就掛了，這個時候限流就非常重要了。舉例來說可以扛得住8000，8000以外的就攔住，不讓進來。比如淘寶去年雙十一零點之后的幾分鐘，有人手機淘寶進不去，或者是支付寶支付不了，就在朋友圈里發截圖說淘寶又掛了，但是沒有多少人回應，因為多數人是可以使用的，他剛好倒霉，是被限流了。有了限流今天來10倍就10倍，來20倍沒有辦法，但是系統扛得住，把其他的流量扔了，保證了基本的收入。
那么最后我們該做的事情都做了，還能怎么辦呢？就只能求佛祖保佑了。這種時候有信仰也許會對你的系統可用性指標有點幫助。不管有沒有用，我們可以努力一下，在自己的代碼注釋當中放上一個佛祖保佑一下。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.hanmeixuan.com/
本文標題：當當網高可用架構之道
相關文章
