更复杂的系统
在互联网及互联网 发展的高速期，简单的单体系统已经无法满足互联网用户的需求，逐渐从单体系统向分布式微服务架构系统演进。演进历程可以概括为以下几个阶段：
- 单体系统：最初通常采用单体系统架构，所有功能模块都集中在一个应用程序中。这种架构简单易用，但随着业务的增长和需求的变化，单体系统往往变得庞大且难以维护。
- 模块化：为了解决单体系统的问题，开始将系统拆分为多个模块，每个模块负责不同的功能。这种模块化的架构使得系统更易于理解和维护，但仍然存在一些问题，比如模块之间的依赖关系和通信方式。
- 分布式系统：为了解决模块化架构中的问题，开始将模块部署在不同的服务器上，形成分布式系统。这种架构可以提高系统的可伸缩性和容错性，但也引入了新的挑战，如网络通信的延迟和一致性问题。
- 微服务架构：微服务架构是一种分布式系统的演化，将系统拆分为一组小型、独立的服务，每个服务都有自己的数据库和业务逻辑。这种架构使得系统更加灵活和可扩展，每个服务可以独立开发、部署和扩展。同时，微服务架构还提供了更好的团队协作和技术栈选择的自由度。
复杂系统面临的挑战
从简单的单体系统架构演进到复杂而庞大的分布式微服务架构系统，系统的复杂度不断的提高，这个架构模式在为开发者提供便利的同时，也带来了很多稳定性、系统韧性的挑战。听过一句话：往往越简单的系统拥有越好的可靠性。
复杂的分布式系统的会有复杂的机制来实现数据一致性、容错能力、限流能力。那么如此复杂的系统如何来保证系统“质量”呢？
往往这里的“质量”都是通过测试人员测试来保证的。来看一个简单的微服务架构：
一般测试人员都是从业务逻辑角度进行功能性测试，系统韧性的上限质量往往是靠有经验的架构师以及开发人员保证的，因为他们更加了解整个复杂系统的架构设计细节；而系统韧性的下限质量是无法简单通过业务测试得到的。因为测试人员不了解系统的架构，也无法进行覆盖到系统架构层面的测试，比如无法模拟网络延迟等会在生产环境中产生的非预期情况。但实际情况就是，往往人们假设极小概率发生的事件给整个系统带来了崩溃性打击。
一个闰秒引起的系统崩溃的案例：
在2012年6月30日的深夜，许多人和往常一样正在Reddit上快乐水贴，突然发现，自己的回复发不出去了。 闰秒故障在Reddit上发生了，起初，Jason Harvey并没有意识到是闰秒加入的问题，仅仅认为是网络质量差的原因。但是问题持续了半个多小时，他们意识到了问题的严重性。最后他们追溯到他们的一组运行着Linux操作系统的服务器上，他们发现，由于没有正常适应当天晚上加入的闰秒，这组服务器几乎完全停顿下来，无法做任何响应。
混沌工程的诞生
从客观来看，类似的问题我们有的可以提前预知到，有的确实完全无法避免（比如自然灾害导致机房不可用等因素）。既然我们无法真正避免一切灾难的发生，最好的办法就是，面向灾难设计，探索系统的韧性边界，验证系统在灾难发生时的恢复能力。简单的系统可能会进行单机宕机就能覆盖绝大部分故障场景，但是一旦系统依赖的服务数量上升，使用的中间件增多，需要进行韧性探索将不再是一个简单的工作了，为了将这部分韧性探索做到极致，就不得不以一个工程化步骤来进行。在这方面，Netflix首先提出了Chaos Monkey（在系统中捣乱的”混沌猴子“）来对目标系统进行随机的宕机测试，评估系统在可用性，容错性等方面的韧性边界，“混沌工程”由此诞生。
如何开展混沌工程实验
腾讯云混沌演练平台（CFG），为您提供安全、易用的的故障注入服务，助您打造稳固如磐石的云架构系统。 无论您是独立开发者、运维工程师还是安全专家，腾讯云混沌演练平台都是您不可或缺的利器：
- 我们拥有丰富的故障动作库，能够模拟IaaS、PaaS、SaaS近百种故障注入场景，可视化的动作编排，让小白也能快速入门，轻松上手构建一个复杂场景的故障演练任务；
- 更值得一提的是，腾讯云混沌演练平台还拥有行业演练经验库。我们汇集了来自各行各业的成功案例和最佳实践，为您提供宝贵的经验和指导。无论您是初学者还是经验丰富的专家，我们都能满足您的需求。
你了解你的云上服务的稳定性边界吗？还在为云上稳定性而忧虑吗？ 马上免费试用腾讯云混沌演练平台，体验一场真实的混沌工程实验吧！
点击链接，立即了解更多关于腾讯云混沌演练平台的信息，一起开启稳定性建设的新篇章！
