“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

举报
评论 0