“The Twelve-Factor App”展开去 - 缓存，延迟及弹性

现在上这个系列的最后一篇文章, 主要介绍缓存，重演延迟, Resilience等话题。之前的两篇请见:

“The Twelve-Factor App”展开去 - SaaS, App, CI/CD

“The Twelve-Factor App”展开去 - 打包，JVM, 自动化基建及BaaS

缓存

软件传递和处理数据时，有时会利用缓存，比如将一些重复使用的信息暂时拷贝在内存，硬盘或数据库中，下次调用时直接从那里拿结果，省去重新计算结果的工序。有时候，鉴于各种缓存工具的优缺点，这种工具还会被组合起来使用。
在阿里云开发社区看到一篇文章，"J2Cache开源中国两级缓存实践", 将ehcache与Redis结合起来使用，即J2Cache.
感觉这个方案有道理。不过里面说，这么做的原因之一是因为重启Java服务后，ehcache缓存里的东西都会清除掉。这个可能是旧版本还没提供相关功能吧。如果没有理解错，据ehcache官网显示，它还是有支持重启的功能的。另外，如何借助缓存来助力软件的实时交互，AWS 在下面文章中给出了介绍:
How to build a real-time sales analytics dashboard with Amazon ElastiCache for Redis

Source: 阿里云开发社区 - J2Cache开源中国两级缓存实践

Source: ehcache

Source: AWS

重演延迟 - Toxiproxy

软件项目中，服务间的网络连接是个通用场景，比如微服务与数据库的连接。开发和测试环境中连接状况好，不代表客户用的时候就没问题。不同的客户的生产环境里，这些连接状况的稳定性也不一样。
如果在开发和测试的时候，能重演这种不稳定性，那就可以及时修正代码，较大程度避免以后找Bug。
使用Toxiproxy可以在连接中架起一层Proxy, 自定义网络的延迟量等等，它可以作为库直接应用到代码中，也支持CLI命令行。
当然，它也不是灵药，也许到最后，出现了性能问题，还是得去找原因，但至少可以多添加点测试场景，灭掉一些隐患。
附上官方github的部分演示，以及DZone里一篇文章提到的应用场景截图。
Designing Fault-Tolerant Microservices With Toxiproxy and Cucumber

Resiliency

记得有一次搭顺风车，司机是个年龄相仿的帅哥，专门给各种活动搭建场地，音响灯光等。他得知我是学计算机相关的，说了一句“听朋友说，搞计算机的人都很有点子”。我当时没太明白，也没觉得。后来接触编程多了，好像渐渐明白了点。
比如一段程序，或者一个服务，不管它跑在哪里，人们会希望它们启动的时候要快。如果因为种种原因要突然中断程序，人们会希望在中断的那一刻，已经传到的输入数据或计算结果能够不被丢失，甚至能尽快处理或传送它们，之后再结束程序。有点像星爷在喊，小强你不能死啊。终止后的程序，人们还希望它能自己再次快速重新启动，继续工作。这样，程序崩溃之后，如果相关人等在忙别的，也不用担心错过了重启的时机。
相关的概念和技术有一系列，比如Crash-only design, Resiliency design pattern, Synthetic monitoring, Automated runbooks, Beanstalkd, RabbitMQ等。类似概念和技术，在云原生中必定也会用到。
上几张截图，来自Uwe Friedrichsen， Grafana 以及Azure.

Source: Uwe Friedrichsen

Source: Grafana

Source: Azure