Dora七牛多媒体容器计算软件

1.0阶段就是从零到一的过程，最开始的架构就是物理机型对应部署规格，但是第三方就要给终端用户提供硬件隔离，所以基于容器架构，当时也是我们自研的容器平台，我们当时会有各种各样的物理机型，但是都有不一样的Disk，为了让每个机器尽量脱离我们可能就会考虑这个机器上部署多少A端应用和多少B端应用，所以我们都会有这种部署规格对应。

可以清晰地看到1.0架构的痛点非常明显，每个架构都是物理机部署，配置多种多样、调整非常麻烦，所以需要很多人进行相应的维护，需要准备机器配置调整，整个过程可能需要半天或者一天，整个机器配置也是相对固定的，要么出现分配不合理，要么出现机器过度竞争。

为了解决1.0的问题我们开发网站运营系统，也有很多集群的方式，我们希望通过统一管理、统一配置应用在某个地区需要多少个，这样便于我们管理每个应用，2.0就是针对就是开发者，包括七牛的开发人员，就是官方应用的提供者，还有就是自定义或者第三方，也会通过这种平台发布应用提供服务。

Dora3.0可以归结为一种愿景，就是开发者关注功能开发，不需要关心可用性，包括分布式的各种痛点都不需要关心，包括自己开发当中遇到的问题我们也会帮助解决。有的开发者是机器识别专家，开发出了固体识别应用，作为一个很厉害的角色，建立一个很厉害的模型，请求当中可能包含图片，最终应用会有识别结果，然后直接上线。

我们可以调用图片格式来转换，如果作为标识的话可以调用，进行图片编辑达到客户需求，有的客户可能觉得图片信息非常多，这些都会大家增加处理的时间，但是时间太长不能同步完成，因为作为机器学习专家也不了解，我们的方案就是平台系统提供统一的用户接口，收到客户消息的时候会转化为请求处理调用应用，反馈结果以后我们可以呈现到异步系统当中，通过这种方式开发者对这样的异步请求就不用自己实现，可以通过我们的平台实现。

现在开发者也会遇到一些问题，比如B服务的处理结果是A服务的临时结果，可能需要多个应用通过数据之间传递，如果是异步结果，图片最终也是标识，实际上最终可能反馈图片地址，也就是异步处理结果的存储，今天这些存储需求我们提供统一存储接口和服务，可以提供简单的需求划分服务，开发者可以通过调用服务接口满足存储需求，整个存储和计算也是解耦的，意味着我们的计算系统可以和任何存储系统结合。

前面说过我们会提供更多的基础服务给开发者，也会提供存储服务，就会发现今天的应用关系会越来越复杂，比如网格状态的关系，具体调用哪个服务，服务的地址是在哪里，如果出现问题我们会怎么覆盖，这些都是我们分布式网格应用面对的问题，所以我们提供智能化调度，能够做到通用化的解决，每个应用都有自己的特例，所以调度都有自己的特殊需求，我们可以对每个应用定义操作策略，通过这些操作策略，至于这个服务在哪里完全是由平台决定。

现在假定我们服务一个外卖厂商，每天到十一点钟就是波峰，但是一般来说到深夜的话请求量就会少很多，所以这样外卖厂商的需求就会有很明显的时间性。过去遇到这样的问题，如果是开发者的话可能需要调整，到了高峰的时候调整到可满足的状态，高峰过去的时候为了节约成本就需要持续缩减，调整不好的话就会影响到SLA。按照这个角度来看，我们需要一个自研的方案，现在方案还是相对比较基础，开发者可以根据自己的应用状况。

（编辑：大连站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!