如果说技术的边缘是发散的, 我就是喜欢杂乱和不成熟的收尾. 就先这么着.
一个不能不提, 又很难讲的东西, 就一句话: 别以为集群不会挂.
正好今天刷微博, 看到这个图, 之前还在想怎么画呢, 就盗过来. 不过里面还少了一行: 同机房远程cache访问, 差不多在1ms左右.
前面说过, cache要靠前. 在云端, 现在有个很有趣的现象, 尤其是私有云: VPS尽量用相同的规格. 在容器化之后, 这个现象更是标准了. 同时, SSD已经成为很大一部分服务器标配了. 参考上图. 所以我有个想法: 把cache放到Host的SSD上去, 似乎是违反当年广为宣传的"远程cache比本地磁盘快"的观点, 因为SSD让这个观点过时了啊!
如果把cache放到Host的SSD上, 有这样的好处:
1. 远超内存大小的cache. 内存cache, 如果是应用使用的话, 有个几G, 已经非常奢侈了; 如果是SSD, 可以增加很多容量.
2. SSD作为cache使用, 速度比内存慢, 但是比访问网络远程缓存快一个数量级. 比如AeroSpike, fatcache完全用SSD作为存储.
3. SSD迟早变成服务器标配, 不要浪费了. 如果服务器是买了SSD公有云的VPS, 更是要用起来.
4. 大块数据或者小文件, 这种偏静态的数据, 如果放在SSD cache上, 可以让内存更加有弹性.
在IaaS层, 有一个问题就是: 如何判断VPS使用是否合理. 前面也提过, 如果不做私有云的资产审计, 就会滥用, 比如用途是tomcat的64G内存的VPS. 这个问题在容器云上一样会存在, 只是相比VPS, 问题变成了: 应用是否合理使用资源. 于是就不再是IaaS部门的问题了, 当然也不是业务部门的问题, 因为公司里面没有归属的问题就不是问题.
其实有一个好用的方法: 大数据系统效率分析.
说人话: 相同技术的跨业务的比较.
说技术化: 类似协同过滤.
假设有两个业务使用tomcat, 都有10+个VPS. 其中一个业务的tomcat VPS内存是16G, 的吞吐是1k qps, 另一个是8G, 2k. 那么, 可能就是有优化空间了. 业务越多, 越能把"特例"和"普遍情况"区分出来.
请注意, 这个策略, 针对的是"应用使用的资源". 在相同技术下, 对资源使用的影响应该只有两方面: 1. 业务逻辑复杂程度; 2. 代码质量. 这个策略如果得到执行, 可以同时起两个作用: 1. 拆封复杂逻辑; 2. 提高代码质量. 当然, 可能KPI的影响可能会导致对业务逻辑的过度拆分. 到时候再合并呗, 合并总是比拆分容易的.
其实前面一节, 已经涉及到了技术储备的问题. 做技术的都知道, 领导讲得一般都是"软技能". 如果IaaS暴露这样的监控信息, 想必会在技术人员间掀起风暴. 想知道谁的技术好, 就看他的tom猫. 一言不合上监控, "你已经击败了98%的其他猫".
这一部分, 没什么能分享的. 不过容器必然带来监控系统的变化, 比如前面说zabbix的screen, 在容器环境下就会有点麻烦. 因为容器的生命周期对数据库而言没多少变化, 对应用而言, 很可能是有比较大区别的.
不过这一块, 同时涉及到metadata的管理. 目前, 能想到的最好的方式, 就是在容器里集成"应用自身的健康检查", 发现自身的性能问题, 就自杀掉.
我还得再发展一下想象力. 反正时间还多, 因为并没有什么线上业务会乐意不停地建容器删容器, 除非吃饱了撑的.