如何利用OSGI实现零宕机？
我正在考虑为我的生产服务器使用 servicemix，我想知道如果我使用 OSGI servlet 是否意味着我可以在不停机的情况下部署新版本的应用程序？如果没有，有没有办法实现服务器零宕机？谢谢。
I am thinking about using servicemix for my production server, I wonder if I use OSGI servlets does that mean I can deploy a new version of my application without downtime? If not, is there a way to achieve zero-downtime server? thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
OSGi 动态服务可能会帮助您升级服务器而无需重新启动它。然而，这表明您的应用程序位于 OSGi 阶梯的顶部。动态获取服务是不够的。应用程序应该在保持活力的同时保持其状态。请参阅 graham Charters 的 OSGi 成熟度模型。 [1]
在现实世界中，零停机时间是通过复制/集群实现的。示例设置如下，两个 serviceMix 服务器，前端由负载平衡器组成。当我们升级一台服务器时，您将负载均衡器指向另一台服务器，反之亦然。只是一个例子。
[1] http://www.infoq.com/news/2011/09/ mmm-osgi
OSGi dynamic services might help you to upgrade your server without restarting it. This however indicates that your application is at the top of OSGi ladder. Dynamically acquiring the service is not enough. Application should preserve its state while achieving dynamism. Refer the OSGi maturity model by graham charters. [1]
In the real world zero downtime is achieved by replication/clustering. example setup is like, Two serviceMix servers , fronend by a load-balancer. When we are upgrading one server you point the load balancer to other vice versa. just an example.
[1] http://www.infoq.com/news/2011/09/mmm-osgi
无论您使用什么，零停机时间都是不可能的。现实世界中有太多的外部因素在起作用。 OSGi 允许服务的不同版本同时运行，允许连接使用较新的服务，然后在最后一个活动连接断开时，旧的 servlet 将被关闭，从而有助于减少升级场景中的停机时间。
Zero downtime is impossible, no matter what you use. There's far too many external factors at play in the real world. OSGi helps mitigate downtime in upgrade scenarios by allowing different versions of a service to run concurrently, allowing connections to use the newer service, and then upon the last active connection's drop, the old servlet will be shut off.
OSGi 可以减少甚至消除单个服务器上的计划停机时间。如果您能够在取消部署旧版本之前部署新版本，则它可以为零（或接近于零，没有区别）。
然而，其他评论者暗示的问题是计划外停机：OSGi 无法使您免于服务器硬件故障。
为了实现弹性，您必须拥有多个服务器，例如集群。一旦有了这个，在一台特定服务器上升级软件需要多长时间（只要不是小时或天）实际上并没有多大区别...）。
OSGi can reduce or even eliminate the planned downtime on a single server. It can be zero (or as close to zero as makes no difference) if you are able to deploy the new version before un-deploying the old version.
However the problem as hinted by other commenters is unplanned downtime: OSGi cannot save you from a hardware failure in a server.
For resilience you must have more than one server, e.g. a cluster. Once you have this, it really doesn't make much difference how long it takes to upgrade the software on one particular server (as long as it isn't hours or days...).
虽然您可以在同一个容器中部署 OSGi 包的多个版本，但这实际上没有帮助，因为您的 servlet 需要绑定到不同的 URL 以避免端口冲突。然后，客户端需要知道如何切换到这个新 URL。这可以通过在代理服务器等中动态更新路由配置来抽象。无论哪种方式，它都会使部署复杂化，并且您的架构在其他方面（HA等）仍然受到限制。
相反，更好的选择是在不同计算机上使用 Servicemix 实例集群（和负载均衡器）。然后在每台服务器上执行标准停止/重新部署/启动以执行升级。这也解决了高可用性和水平可扩展性需求等。
Though you can deploy multiple versions of an OSGi bundle in the same container, this really doesn't help because your servlets would need to bind to different URLs to avoid port conflicts. Then, clients would need to know to switch to this new URL. This could be abstracted by updating routing configuration dynamically in an proxy server, etc. Either way, it complicates deployment and your architecture is still limited in other ways (HA, etc).
Instead, a better option would be to use a cluster of Servicemix instances (and a load-balancer) on different machines. Then do the standard stop/redeploy/start on each server to perform an upgrade. This also addresses high availability and horizontal scalability needs, etc.