现在上这个系列的最后一篇文章, 主要介绍缓存，重演延迟, 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
