[重要] 关于流量即将耗尽的通知以及应对办法

[bitdust]

情况说明

目前这个工具正在使用Cloudinary的CDN作为图片缓存，以免对 向日葵-8 的官网造成流量压力，以达到延长API寿命的目的。
这个工具的火爆程度超出了我的预计，甚至冲上了github的C# trending榜首。在此必须感谢大家的鼎力支持。然而这带来的一个副作用就是我的CDN账户已不堪重负，如下图所示，最高峰时已达到 26GB/天 ！即使我在1.1版本中紧急增加了负载均衡功能依然是杯水车薪。

而我并不能负担如此高的开销，之前计划使用VPS做反向代理的计划也因意外而搁浅。（某B开头的VPS服务商因为我填写的个人资料不完整而封停了我的帐号，233）。
总之，按当前情况来看，Cloudinary迟早会因为流量爆炸而封停封停我的帐号，到时所有客户端将不能正常更新图片。

解决方案1

进入Settings窗口，切换图片源为orgin。
但是个人非常不推荐这个办法， 因为如果大家都这么做的话，会给官方造成很大的流量压力和困扰。很可能导致API被封锁。

解决方案2

申请使用私有的CDN账户。按照曾经的估算，一个Cloudinary的免费CDN账户可以支撑10个人不间断的24小时图片抓取。因此如果有能力的话，使用个人的CDN帐号可以一劳永逸的解决这一问题。
具体步骤如下：
1.前往Cloudinary官网注册账户。
记录你的Cloud name

2.编辑你的EarthLiveSharp.exe.Config文件
将 CDN 或CDN1、CDN2、CDN3、CDN4 键值对应的红框所圈中的内容全部都修改为你的Cloud name 即可。

3.Cloudinary会向你的注册邮箱发一封验证邮件，记得查收并验证。

附言

最后还想说点什么，做这个程序只是处于排解近来压力的个人爱好。但是盗用他人API总归是一个不道德行为，现在爆掉了自己的CDN也是一个报应吧！开源软件的意义在于分享自己的喜悦和成果，而非免费的使用别人的服务。可惜自己代码写的又很糟糕，没有什么学习价值，所以这个项目到头来的存在意义就只是骗了200个星星而已。233~
总之呢就是，对自己的任何行为都要负责，不要做慷别人之慨，替别人“开源”。
随着流量耗尽，这个项目可能就要暂停一个段落了，当然出了什么严重bug的话我还是要负责去修的。
最后再次感谢大家支持！

[bitdust]

Why should you use your own CDN account?

As you can see, this software cost a daily bandwidth of 26GB, which is far beyond my quota (about 30GB/month). It means my CDN may be out of service at any time.

So please register for your own CDN account to keep EarthLive# working.

How to switch to your private CDN account?

1.Please go to www.cloudinary.com and then register for an account.

2.Copy the Cloud name.

3.Edit the file : EarthLiveSharp.exe.Config

4.Paste the Cloud name to ALL MARKED LOCATION.

5.done.

[spin6lock]

能不能用bt模块做分发啊？你的CDN同时作为tracker，让用户互相分享一下照片

[bitdust]

@spin6lock 有趣的想法。
这个和ed2k以及bt并不一样，需要在10分钟内完成对所有用户的数据分发。很类似当年的P2P视频直播，需要发送的是图片流，不过也并不需要太强的实时性和带宽。。。
唔，应该会很有用的东西，而且现在还没有。
可是这应该是远远超过桌面壁纸小工具的项目了，无论是难度上还是任务量上。

[lizy14]

不是类似，它本质上就是。。帧频很低的视频直播。。。

我觉得可以一搞，除了日本这个向日葵8号的全彩图，还有一些别的资源可以用来做动态更新的桌面壁纸，比如说除了天上的卫星，还有

• 北京气象铁塔

甚至一些实时数据的可视化结果，当然就没有那么炫酷了。。

[bitdust]

@lizy14 还能发掘出更多的需求吗？（而不只是更新壁纸的）
说起来这个叫EarthLive而不是 himawari-8 live的原因就是想到以后可能去抓其他源的图片~
不过之后就被流量问题教训了。
现在看来有一个P2P的（准实时）推送系统就很重要了，而且也许其他地方也用得到

[Bustycat]

如果先把图像转成JPEG再发布应该能节省不少流量。

[bitdust]

@Bustycat 然而图片转换操作也需要配额~一个月只能进行7500次操作

[spin6lock]

这个可以自己在vps上完成吗？毕竟转换操作频次不高，也有现成的库可以做
bitdust notifications@github.com于2015年12月22日 周二20:38写道：

@Bustycat https://github.com/Bustycat 然而图片转换操作也需要配额~一个月只能进行7500次操作

—
Reply to this email directly or view it on GitHub
#13 (comment)
.

[bitdust]

应该能节省流量，但是又需要一套脚本~和VPS，并且我相信大家对图像二次压缩都有抵触吧。
最后我现在不打算背流量这个锅了，现在只是提供程序，如果想安心使用的话，还是去自己申请个CDN服务也一点不麻烦的。

[Bustycat]

有人也做了一个
http://www.oxo.ooo

[yogkang]

希望大家都可以申请自己的cdn,不希望官方吧API封锁了.

[sorz]

CloudFlare 能解决吗

[bitdust]

@sorz
使用Cloudinary更方便

[Sean-Pearce]

请问如何更改图片分辨率呢？看起来好小啊。。。

[xingrz]

@bitdust 其实（如果我没理解错的话）方案 2 对官网产生的流量并没有减少，只是经过了 Cloudinary 中转而已。

---

@Bustycat OXO 那个是我做的，但不会给官网增加压力。我的服务器每 10 分钟会以 4d 分辨率从官网抓取图片后合并保存到我自己的七牛 CDN 空间里，之后客户端的流量全部都是打到七牛上的（同时因为七牛支持 WebP 压缩所以能给客户端节省很多流量）。然而，因为这些都是个人承担的真金白银的流量支出，请原谅我并不能将我的七牛地址公布出来。

[momoca]

我不明白显示图片可以从网(http://himawari8.nict.go.jp/)上自游下载.为什么你要转到空间上另存一份呢?
是原站有限制吗?

[bitdust]

@xingrz 哇，馒头地球的作者！
这个也是个CDN的接口。第一个人调用这个接口后，图片是会被自动缓冲到CDN里的。之后的话，所有人都是从CDN的缓存里获取的数据。
所以流量压力在CDN这里就已经被截住了。

@momoca 如上所说，是为了截住流量，不给源服务器太大压力。

[xingrz]

@bitdust 意思是说 Cloudinary 其实是有全局的缓存，即便在不同的帐号里？

[bitdust]

@xingrz 是的，他的缓存是全局不分账户的。
顺便一问，你大概在CDN上投了多少钱啊？

[xingrz]

@bitdust 还没月结（但也快了，今天31号了）所以具体还不知道

但这几天也是一天烧个20G左右…七牛是前10GB免费，后面0.29元/GB…上线到现在已经烧了120G…

不过还好，本身 WebP 的体积就比 PNG 要小个 90%…

[bitdust]

@xingrz 明白了，七牛的服务果然不错。我这个只能买套餐，然后发现直接买不起了
不过这么看来，WebP果然厉害！

[xingrz]

@bitdust 我看了一下 Cloudinary 似乎也支持 WebP 的，可能可以帮你节省不少下载流量。

[bitdust]

@xingrz 嗯，有机会试试。

[momoca]

@bitdust 谢谢你的解答.

[1a57danc3]

準備一台VPS，利用api拉取himawari8.nict.go.jp的圖片，然後將這些圖片git push到coding/oschina的git服務上，利用raw外鏈出來。

[xingrz]

@ky0ncheng 这种做法是可耻的

[1a57danc3]

raw url 既然存在，那存在的意義就是如此。

感謝道德高地。

[xingrz]

感謝道德高地。

还记得当年12306抢票插件拖垮 GitHub 的事件么… 😓

[bitdust]

@xingrz
嗯，我也觉得使用git做分发不是个好方案，而且必然不稳定的风险很大。
刚好看见你路过，顺便一提，你家馒头地球的有时候会变黑白照片。而且似乎不是官网的原因。因为的馒头地球是黑白的同时我抓的图片是彩色的。有点怀疑是你的CDN转码的原因。
算了，要不等我找的证据再说。。。

[xingrz]

@bitdust 谢谢

[alalalading]

除了550x550的，还有什么分辨率，电脑上看着有点糊