javasocket服务器端接受的消息如何转发给另一个客户端?_你是一个成熟的程序员了，是时候学习面向故障编程了...

作为程序员，最大的噩梦，可能就是下班时间，当我正在开心的浪着，突然传来一阵急促的铃声，运维的同事说系统不行了，我必须马上上线帮忙抢救...... 之前还看过一个更惨烈的新闻，有一位程序员新郎，在自己的婚礼上，还不得不上线维护系统......

等你好不容易折腾了半天，终于把系统稳定住了，还没来得及喘口气，老板就顶着一张黑脸，发出了灵魂的拷问：为什么测试的时候没发生问题，生产环境里却出了故障？

这是一个价值百万的问题。我来试着帮你回答一下：

• 功能测试只覆盖了正面测试(positive test)，而忽略了负面测试(negative test)
• 整合测试没有覆盖到的某个在生产环境中引起故障的外部系统
• 没有进行压力测试，或者压力测试的程度与生产环境情况相差过大

这个清单还可以一直写下去。你不妨检视一下你自己的测试环境和测试设计，相信你还会发现更多的不足。

老板看着这个清单，脸色越来越黑。接下来，他问出了更扎心的问题：今后怎么避免类似的故障再发生？

你眼睛一亮，举起你刚刚列出的测试环境缺点清单，向老板保证你会把清单上每一个缺点都改正过来！

然而，这真的是最好的解决方法吗？

加强测试覆盖度是非常值得提倡的做法。但是，这未必能避免生产环境中故障的发生。因为测试环境终归和生产环境不同。如果你只是为了能通过测试而进行开发，那你的产品上线之后，注定要暴露于新的风险之下。

今天，我们就要来探讨一下，除了依赖测试，开发人员还有什么更好的办法来打造更加健壮的系统。

首先，我们来思考一下，故障是什么？今天我们不去探讨bug，因为理论上来说，有bug的系统根本不能通过基本测试，也就不会被部署到生产环境。如果任何bug侵入到了生产环境，造成了服务的中断或系统事故，那这个责任必然要由开发人员和测试人员一起承担。

今天我们想要探讨的，是在生产环境中，常常被归因于"外部"因素或者环境因素所造成的故障。比如配置不正确的防火墙屏蔽了系统发送的请求。比如其他客户大量访问数据库，从而阻塞了我的系统发出的数据库请求。比如上游系统发生故障，突然发送了海量的垃圾消息等等。

遇上这样的故障，我们会说，"真是倒了霉了"，"今天运气不好"，"天有不测风云"。也就是说，我们认为在生产环境中遇到故障是种"异常"情况，所以我们的系统才无法"正常"运行。

今天，我要扭转这个观点，在一个成熟的程序员眼里，生产环境中的"故障"才是"真实"，"异常"才是"正常"。墨菲定律告诉我们：有可能出错的地方，就一定会出错。在生产环境中，有可能发生故障的地方，早晚都会发生故障。作为开发人员，我们能做的，就是利用各种设计模式和技巧，主动积极地去正视故障，处理故障，修复故障，将故障杀死于襁褓之中。这种思想，就叫做面向故障编程。

大家跳过的