有关三个九可用性的信息
我将开发高可用的 WCF 服务，为客户提供 99.9% 的正常运行时间。正如您可能猜到的那样，我需要尽可能多的信息。 所以我知道，在 stackoverflow 上，有很多专业人士在帮助像我这样的新手 :) 因此，如果您向我指出制作 .NET WCF 服务的良好经验，那对我来说会非常好。 该服务将与许多地理位置偏远的数据库配合使用，并向客户提供来自这些数据库的数据。 任何文章、链接、博客/论坛帖子和个人回忆都将不胜感激。 提前致谢！
I'm going to develop high-available WCF service that should serving client with 99.9% uptime. As you probably guess I need as more information as possible.
So I know here, on stackoverflow, a lot of professionals helping newbies like me :) So it would be so good for me if you point me at good experience on making .NET WCF services.
This service will work with a lot of geographically remoted databases and will provide clients data from them.
Any articles, links, blog/forum posts and personal memories will be very appreciated.
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
没有一个相关的方面，而是几个......只是需要考虑/牢记的一些要点：
冗余
无论是并行运行服务的多台机器，还是在一台机器停机/无法访问时提供帮助的某种基于 DNS 的机制...无论是不同机器的不同物理位置（数据中心），还是不同的骨干连接（ ISP)...无论是冗余数据库后端（如 Oracle RAC 设置）等。
安全性
这必须从一开始就是您设计的一部分...您需要服务本身强大的安全性（基本的东西，例如彻底检查所有传入数据）和运行时环境（例如防火墙等）
备份
这部分必须经过深思熟虑并进行最大程度的测试...有不同的技术，例如备份和运行的速度等。 - 有时您需要结合多种技术...再次：测试您的最坏的情况
监控
为了确定发生了什么并尽早做出反应，您需要一个良好的监控实施...这从铁向上开始并在服务内部结束...它不仅应该检查可用性，还应该检查负载等内容，并且可配置的警报...它也需要允许历史记录...这反过来又为您提供足够的数据来了解何时是高峰时间和/或何时添加新机器等。
测试
使用任何可用的工具确实很难检查您的服务...无论是内存分析器，还是使用现实场景进行负载测试，甚至是极端场景...
可扩展性
无状态服务通常在可扩展性方面更好......
计划
非常重要，根据我的经验，通常会被遗忘或不更新...制定部署、部署/更新、灾难恢复等计划。最重要的是：彻底测试它们并记录它们！
There is not one relevant aspect but several... just some points to consider/keep in mind:
Redundancy
Be it multiple machines running the service in parallel, be it some DNS-based mechanism to help when one machine is down/not reachable... be it different physical locations (Data centers) for the different machines, be it different Backbone connections (ISP)... be it a redundant DB backend (like an Oracle RAC setup) etc.
Security
This must be part of your design from the beginning... you need strong security in the service itself (basic things like checkng all incoming data thoroughly aside) and the runtime environment (like firewalls etc.)
Backup
This part must be well thought through and tested to the fullest extent... there are different technologies which differ for example in how fast you are back up and running etc. - sometimes you need to combine multilple techniques... again: test your worstcase scenario
Monitoring
To be sure what goes on and to react as early as possible you need a good monitoring implementation... this starts from the iron upwards and end inside the service... it should no only check availability but also things like load etc. and configurable alarming... it need to allow for history too... which in turn gives you enough data to know when are the peak hours and/or when to add new machines etc.
Testing
Check your service with any tool available really hard... be it a memory profiler, be it load testing with realisitc scenarios, even with extreme ones...
Scalability
Stateless services usually are better in terms of scalability...
Plans
Very important and usually forgotten or not up2date in my experience... make plans for deployment, rollout/updates, desaster recovery etc. AND most important: test them thoroughly and document them!
我建议在负载平衡器后面放置多个服务器。
此外，您可能需要另一个地理位置偏远的远程位置来确保这种正常运行时间。
I'd recommend having multiple servers behind a load-balancer.
Also, you may need another geographically removed remote location to ensure that kind of uptime.
哈哈哈。严重地。
99.9 是“机架中的普通计算机”，而不是“高可用性”。请算算一下。 99.9% 的可用性是每年 3.65 天的停机时间。如果你有普通的电脑，包括维修，我会说它是蹩脚的。
这种可用性级别是“从戴尔购买服务器，并在 24 小时内派技术人员到现场，以防出现故障”。
Hahahhaahaha. Seriously.
99.9 is "normal computer in a rack", not "high vailable". Make your math, please. 99.9% availability is 3.65 days per year downtime. I would call a normal computer crappy if you have that - including repairs.
This level of availability is "buy a server from dell with a technician on site within 24 hours in case something fails".