新功能]边缘计算？近场加速？为云影像落地穿上加速的翅膀

今天干货太多，就不扯那些闲的，直接进入正题吧。我们今天是要官宣：我们针对一个让云影像不那么爽又不容易发现的问题，推出了一个全新的组件，并且让我们的云影像方案向前迈进了一大步，这步子甚至大到了一个质变的程度。

先从问题说起：随着越来越多的机构开始了全部或者部分影像上云，通过我们大量的不计成本、不限流量的CDN甚至拉专线等技术手段，让医生在家里，或者外面的专家通过互联网，可以方便、快速的调阅影像了。但有一个以前未重度使用云影像时不会暴露的问题就显现出来了：在机构内工作的大量医生调阅影像对医院的总带宽的抢占效应明显，并且医院的出口总带宽也不是无限大的，采购大带宽宽带的成本也不低。由于医院的医生更多，影像调阅也更频繁，或者机构带宽也无法满足大量的医生同时调阅影像的要求，造成在工作时段在机构内调阅速度的缓慢，严重影响了医生，特别放射科医生的工作效率。

要解决这个机构内医生调阅抢占机构总带宽的问题，有一个简单直接的办法就是直接在影像上传的时候将影像截留保存起来，以便在机构内用户调阅时直接访问。以前有一个简单的办法就是在机构内安装一套PACS，机构内的访问都直接访问PACS的网址，然后在互联网外再访问另外的网址。这实际上是内部和外部两套系统，后台进行一些数据同步机制进行同步。这种方案在只是调阅影像还简单一些，如果加上了报告等流程时，流程状态及数据的同步将是一个灾难。严格的讲，这种方案甚至都不能称之为云影像方案。

而我们这次针对这个问题推出的解决办法就是在机构内增加一个近场加速模块，此模块只负责加速影像访问的加速。在严格的DICOM工作模式下，每个检查、每个序列甚至每个图像都有唯一的uid进行标识，因此我们可以在影像调阅时，程序自动在后台根据各级uid判断影像检查/序列/图像在近场加速中是否存在，如果存在的话直接访问近场加速中的影像，如果不存在则直接访问云端影像即可。此方案特别适合使用全云方案，且内部也有大量医生访问影像的机构和场景，如医院，独立影像中心等。

上图是我们以前版本的云影像架构图，这里面包含了大量从医院上传影像，通过互联网调阅影像的优化措施，唯独缺少了对机构内调阅的优化支持。按照新的这个方案来，我们的整体的架构图会变成下图这样。这里需要强调一下的是，近场加速模块只是部署在机构内网，且仅在后台响应影像调阅请求，并不直接提供用户的访问入口。用户全程无需任何操作即可在机构内部快速访问影像；而在医院外部则自动访问云端的影像数据。云影像系统仍是一套系统，提供统一的访问入口。

在调阅加速的基础上展开来讲，由于在近场加速模块保存了大量的影像，且其中的影像的保存周期也是可以按需配置的。因此除去用于影像的访问加速之外，此模块甚至也可以用于在机构内归档存储历史影像，再延展来说的话，能支持几种应用场景的区分：一是云端只保存近一两年的数据，从而在近场加速模块中保存全部历史数据，这个时候改叫本地归档模块也不无不可；另外一种就是在云上保留全部数据，在近场加速中只保留最近一两年的数据，从而可以在机构内以一个低成本的服务器即可达到一个较好的加速效果；当然还有第三种方案，那就是在近场加速和云端中都保留全部数据。大家可以按需按预算选配相关方案组件。

上面都是讲的近场加速方案的优点，那近场加速方案有没有什么缺点呢？还真有一个：部署近场加速模块需要一个服务器，且其配置随着访问用户多少也需要按需增加。当然机构内用户越多，带来访问速度提升的获益就更大，成本节约的也更多。如标题所讲，近场加速可能解决了大家影像上云的最后一个技术阻碍了。关于影像上云，大家还有什么其他的技术上的阻碍么，欢迎留言告诉我们！

说了这么多干货了，还都是没有界面的纯技术干货，都是相当枯燥技术内容，就不给大家推日常的宣传推广了。就继续给大家安利一下我们的微信DICOM影像调阅小程序：想要直接在微信里打开DICOM影像，请直接搜索“微至云动影像小程序”。谢谢大家！