江苏龙网

  1. 主页 > 生活百科 > >

复杂性也是IT成本，你明白了吗？

it

7Signals从公有云撤退后还应该继续类似公有云商的技术堆栈，继续使用K8S，但是他们连K8S都放弃了，改为私有云虚拟机+Docker，就值得我们更仔细的去研究一番了 。为了更好地了解这个事件，我一大早又看了一遍rework对David和37Signals COO Eron Nicholson的访谈的文字稿 。实际上从访谈中我们可以获得更多的值得思考的线索，不过很多内容不在今天要讨论的范围内，以后找机会再聊吧 。
从这个访谈中，我看到了很多对于这个问题思考的细节，David他们当初上云的目的是解决IT的复杂性问题，他们可能会面临系统上线两周后的几十万访问的尖峰，公有云很好地帮他们熬过了这个时期 。随着业务的不断成熟与扩大，系统负载变得很平稳，没有黑色星期五的销售量暴增，也没有圣诞假期的低谷 。于是业务的发展，IT系统的负载变得十分容易预测了，因此需要公有云解决的复杂性问题不存在了 。此时带来了一些新的复杂性，公有云对于37Signals来说是一个黑匣子，它是否真的安全、可靠，只有出了问题才知道，在此之前，它就像一场梦一样不可捉摸 。

复杂性也是IT成本，你明白了吗？

文章插图
37Signals付出了高额的成本，但是他们还是买不起更高级别的服务，亚马逊并不能及时接听他们的电话，遇到的所有问题也必须由他们自己的运营团队来解决 。因此上云数年后公有云并没有真正帮他们解决掉复杂性的问题，只是让他们的运营成本变得更高了 。
对于他们回归自营虚拟机+DOCKTER，则是对复杂性的另一个思考，他们认为K8S太复杂了，其陡峭的学习曲线让他们感到力不从心 。当一切都正常时，大家都觉得K8S很不错，用起来很省心，但是一旦出问题的时候，他们是无力解决这些问题的 。对于一个拥有数十万注册用户，但是只有80多人的中型SAAS服务商来说，很好地掌握K8S的复杂运维并不是一件容易的事情，因此他们最后决定将K8S上的应用退回到虚拟机+DOCKER的环境中，复杂度的降低让他们对整个系统的把控能力提升了许多，他们的十几个人的运营团队可以十分轻松的把控整个平台和系统了 。而之前他们的系统一直为不太必要的系统复杂性的可能性买单，从而面临诸多的运维挑战 。
大型互联网企业的业务面临巨大的不确定的负载挑战，因此他们的系统可以面向各种各样的复杂性 。因此他们从头到尾构建了一套IT体系，从研发到运营，这套体系是完全适应这个IT基础平台和技术堆栈的 。近些年来，大型互联网企业也在做技术输出，很多传统企业也接受了这种技术输出 。但是这些传统企业往往只能学其表，而无法做到表里一体 。因此他们引入大型互联网企业的技术的同时也引入了IT的复杂性，但是并没办法掌握解决复杂性问题的方法 。同时，这些企业的业务与互联网企业完全不同，他们也并没有那么多的复杂性要去解决 。他们实际上并不需要掌握解决这些复杂性的钥匙，因此他们拿到钥匙之后并不知道门在哪里 。
【复杂性也是IT成本，你明白了吗？】实际上很多企业或者团队低估了复杂性所带来的成本，因此过于强调了敏捷和可扩展性带来的好处 。这几年我一直跟踪一个项目，这是一个面向近百万用户使用的管理类系统，其在线用户数最终会突破10万 。最初设计是从以前的Oracle数据库迁移到RDS MySQL作为数据库 。他们最初选择了32C/128GB的标准RDS实例，每个数据库不超过500GB容量 。在研发过程中，他们解决了很多分库分表的难题，通过一年多的时间，终于完成了应用的改造 。上线试运行阶段他们解决了大量的性能问题，对数据库做了进一步的拆分 。不过随后他们发现，如果完成整个系统上线，数据库系统将需要被拆分为120+个RDS实例，而如果为了进一步提升处理能力，为今后系统长期运行做准备，必须使用读写分离的方式，如果这样，他们可能需要将整个系统拆分为360+实例 。在一个系统中创建与运维如此大数量的RDS实例，让他们感到恐惧 。
为了解决数据库的复杂性问题，他们又开始对数据库实例进行合并，将120+的数据库实例都改为大规格的90C/720GB的MYSQL实例 。这样就把数据库实例的数量减少为40+，不过每个数据库的容量也变成了1.5TB 。看到这个新的数据库设计，很多人觉得放心多了，不过我也提出了一个新的问题，运维一个23C/128GB，小于500GB的MYSQL数据库实例与运维一个90C/720GB，1.5TB的MYSQL实例的难度相同吗？我想很多了解MYSQL，深度使用过MYSQL的朋友心里已经有答案了 。


推荐阅读


上一篇：五分钟搞定验证码，你学会了吗？

下一篇：CSS 遮罩合成实现带圆角的环形 loading 动画