Dora可以分為兩個部分：官方數據處理主要包括圖片基礎處理，此外包括智能審核和智能識別，如果上面的技術應用不能滿足需求，可以自己編寫應用，也就是自定義處理，第三方平臺也可以在上面部署應用服務七牛的客戶。支撐海量應用需要多集群的管理平臺，需要管理物理資源和海量應用，包括數十個機房、數千個容器應用、海量圖片和視頻計算。

1.0階段就是從零到一的過程，最開始的架構就是物理機型對應部署規格，但是第三方就要給終端用戶提供硬件隔離，所以基于容器架構，當時也是我們自研的容器平臺，國內服務器租用服務器托管，我們當時會有各種各樣的物理機型，但是都有不一樣的Disk，為了讓每個機器盡量脫離我們可能就會考慮這個機器上部署多少A端應用和多少B端應用，所以我們都會有這種部署規格對應。

可以清晰地看到1.0架構的痛點非常明顯，每個架構都是物理機部署，配置多種多樣、調整非常麻煩，所以需要很多人進行相應的維護，需要準備機器配置調整，整個過程可能需要半天或者一天，整個機器配置也是相對固定的，要么出現分配不合理，要么出現機器過度競爭。

為了解決1.0的問題我們開發網站運營系統，也有很多集群的方式，我們希望通過統一管理、統一配置應用在某個地區需要多少個，這樣便于我們管理每個應用，2.0就是針對就是開發者，包括七牛的開發人員，就是官方應用的提供者，還有就是自定義或者第三方，也會通過這種平臺發布應用提供服務。

Dora3.0可以歸結為一種愿景，就是開發者關注功能開發，不需要關心可用性，包括分布式的各種痛點都不需要關心，包括自己開發當中遇到的問題我們也會幫助解決。有的開發者是機器識別專家，開發出了固體識別應用，作為一個很厲害的角色，建立一個很厲害的模型，請求當中可能包含圖片，最終應用會有識別結果，然后直接上線。

我們可以調用圖片格式來轉換，如果作為標識的話可以調用，進行圖片編輯達到客戶需求，有的客戶可能覺得圖片信息非常多，這些都會大家增加處理的時間，但是時間太長不能同步完成，因為作為機器學習專家也不了解，我們的方案就是平臺系統提供統一的用戶接口，收到客戶消息的時候會轉化為請求處理調用應用，反饋結果以后我們可以呈現到異步系統當中，通過這種方式開發者對這樣的異步請求就不用自己實現，可以通過我們的平臺實現。

現在開發者也會遇到一些問題，比如B服務的處理結果是A服務的臨時結果，可能需要多個應用通過數據之間傳遞，如果是異步結果，圖片最終也是標識，實際上最終可能反饋圖片地址，也就是異步處理結果的存儲，今天這些存儲需求我們提供統一存儲接口和服務，可以提供簡單的需求劃分服務，開發者可以通過調用服務接口滿足存儲需求，整個存儲和計算也是解耦的，意味著我們的計算系統可以和任何存儲系統結合。

前面說過我們會提供更多的基礎服務給開發者，也會提供存儲服務，就會發現今天的應用關系會越來越復雜，比如網格狀態的關系，具體調用哪個服務，服務的地址是在哪里，如果出現問題我們會怎么覆蓋，這些都是我們分布式網格應用面對的問題，所以我們提供智能化調度，能夠做到通用化的解決，每個應用都有自己的特例，所以調度都有自己的特殊需求，我們可以對每個應用定義操作策略，通過這些操作策略，至于這個服務在哪里完全是由平臺決定。

現在假定我們服務一個外賣廠商，每天到十一點鐘就是波峰，但是一般來說到深夜的話請求量就會少很多，所以這樣外賣廠商的需求就會有很明顯的時間性。過去遇到這樣的問題，如果是開發者的話可能需要調整，到了高峰的時候調整到可滿足的狀態，高峰過去的時候為了節約成本就需要持續縮減，調整不好的話就會影響到SLA。按照這個角度來看，云服務器租用，我們需要一個自研的方案，現在方案還是相對比較基礎，開發者可以根據自己的應用狀況。

由于數據開放驅動的需求，我們的方案就是收集應用協議，就是將應用數據反饋給我們的整體途徑，我們搜集這些應用然后找到大數據系統，應用開發者可以通過比較常見的大數據方式搜索分析應用，然后來做持續迭代和改進。今天我們對每個應用都有基礎監控日志的能力，一般來說常見應用尺度包括請求時延，然后在日志平臺當中展示，客戶可以搜索日志來做改進。通過集群多活的方式，某個機制出現問題的時候，應用開發者不用關注，我們可以自動調度，就是將有問題的集群流量進行調度，也可以繼續服務客戶。

我們最終的愿景還是希望開發出來一個系統，能夠大大簡化應用開發。