Dora可以分为两个部分：官方数据处理主要包括图片基础处理，此外包括智能审核和智能识别，如果上面的技术应用不能满足需求，可以自己编写应用，也就是自定义处理，第三方平台也可以在上面部署应用服务七牛的客户。支撑海量应用需要多集群的管理平台，需要管理物理资源和海量应用，包括数十个机房、数千个容器应用、海量图片和视频计算。
1.0阶段就是从零到一的过程，最开始的架构就是物理机型对应部署规格，但是第三方就要给终端用户提供硬件隔离，所以基于容器架构，当时也是我们自研的容器平台，我们当时会有各种各样的物理机型，但是都有不一样的Disk，为了让每个机器尽量脱离我们可能就会考虑这个机器上部署多少A端应用和多少B端应用，所以我们都会有这种部署规格对应。
可以清晰地看到1.0架构的痛点非常明显，每个架构都是物理机部署，配置多种多样、调整非常麻烦，所以需要很多人进行相应的维护，需要准备机器配置调整，整个过程可能需要半天或者一天，整个机器配置也是相对固定的，要么出现分配不合理，要么出现机器过度竞争。
为了解决1.0的问题我们开发网站运营系统，也有很多集群的方式，我们希望通过统一管理、统一配置应用在某个地区需要多少个，这样便于我们管理每个应用，2.0就是针对就是开发者，包括七牛的开发人员，就是官方应用的提供者，还有就是自定义或者第三方，也会通过这种平台发布应用提供服务。
Dora3.0可以归结为一种愿景，就是开发者关注功能开发，不需要关心可用性，包括分布式的各种痛点都不需要关心，包括自己开发当中遇到的问题我们也会帮助解决。有的开发者是机器识别专家，开发出了固体识别应用，作为一个很厉害的角色，建立一个很厉害的模型，请求当中可能包含图片，最终应用会有识别结果，然后直接上线。
我们可以调用图片格式来转换，如果作为标识的话可以调用，进行图片编辑达到客户需求，有的客户可能觉得图片信息非常多，这些都会大家增加处理的时间，但是时间太长不能同步完成，因为作为机器学习专家也不了解，我们的方案就是平台系统提供统一的用户接口，收到客户消息的时候会转化为请求处理调用应用，反馈结果以后我们可以呈现到异步系统当中，通过这种方式开发者对这样的异步请求就不用自己实现，可以通过我们的平台实现。
现在开发者也会遇到一些问题，比如B服务的处理结果是A服务的临时结果，可能需要多个应用通过数据之间传递，如果是异步结果，图片最终也是标识，实际上最终可能反馈图片地址，也就是异步处理结果的存储，今天这些存储需求我们提供统一存储接口和服务，可以提供简单的需求划分服务，开发者可以通过调用服务接口满足存储需求，整个存储和计算也是解耦的，意味着我们的计算系统可以和任何存储系统结合。
前面说过我们会提供更多的基础服务给开发者，也会提供存储服务，就会发现今天的应用关系会越来越复杂，比如网格状态的关系，具体调用哪个服务，服务的地址是在哪里，如果出现问题我们会怎么覆盖，这些都是我们分布式网格应用面对的问题，所以我们提供智能化调度，能够做到通用化的解决，每个应用都有自己的特例，所以调度都有自己的特殊需求，我们可以对每个应用定义操作策略，通过这些操作策略，至于这个服务在哪里完全是由平台决定。
现在假定我们服务一个外卖厂商，每天到十一点钟就是波峰，但是一般来说到深夜的话请求量就会少很多，所以这样外卖厂商的需求就会有很明显的时间性。过去遇到这样的问题，如果是开发者的话可能需要调整，到了高峰的时候调整到可满足的状态，高峰过去的时候为了节约成本就需要持续缩减，调整不好的话就会影响到SLA。按照这个角度来看，我们需要一个自研的方案，现在方案还是相对比较基础，开发者可以根据自己的应用状况。
由于数据开放驱动的需求，我们的方案就是收集应用协议，就是将应用数据反馈给我们的整体途径，我们搜集这些应用然后找到大数据系统，应用开发者可以通过比较常见的大数据方式搜索分析应用，然后来做持续迭代和改进。今天我们对每个应用都有基础监控日志的能力，一般来说常见应用尺度包括请求时延，然后在日志平台当中展示，客户可以搜索日志来做改进。通过集群多活的方式，某个机制出现问题的时候，应用开发者不用关注，我们可以自动调度，就是将有问题的集群流量进行调度，也可以继续服务客户。
我们最终的愿景还是希望开发出来一个系统，能够大大简化应用开发。
热门专题
