基于微服务的架构是未来的趋势,但是实现这种架构会面临许多困难。现代应用架构远比过去的架构复杂,因此实现微服务架构将会带来了一系列特殊的挑战,而服务网格可以帮我们解决很多问题。
最近一段时间,管理者不再专注于调试单个应用程序服务器,相反,现代系统就像是一群牛,研究整体的行为远比单个的服务器有意义,分布式系统就是一个典型。
微服务是一种分布式架构,目的在于通过不断调整自身以适应当前流量状况的变化,例如,有一组处理客户端请求路由的容器,改变这组容器,反过来也意味着路由表在不断变化,由此反映了应用程序端点的变化位置。与此同时,在任何架构体系中都会有过去的遗留物,从必须使用单个大型数据库服务器的应用程序到捆绑API以使其看起来是以服务为重点的遗留系统。
而服务网格是当前最先进的微服务模式。它建立在容器以及容器编排之上,配有处理内部服务通信的专用控制面。它负责协调分布式网格的微服务所需的安全性,路由,身份验证,授权和类似功能,服务网格将这些功能从应用程序(或应用程序的服务组件)中剥离出来作为可编程的基础组件。虽然不是所有的公司都需要如此复杂的服务网格(尽管这些公司大部分都运行着成百上千的服务),但服务网格正迅速成为那些希望运行生产级微服务的公司的默认架构。
以下是八种实现服务网格的方法,可以帮助您平滑过渡到微服务。
改进微服务的消息处理机制。服务网格确保你能监控到整个架构层,不仅可以跟踪到网络中的服务器地址,还可以跟踪到传达服务器地址信息的消息。例如,你可能想要跟踪“失败”消息,但这些消息在传统云架构中通常会丢失。服务网格的好处是既可以确保消息的传递,又会在消息未到达目的地时返回错误信息。
利用与传统应用程序相同的运维方式。对于企业级网络来说,可定制性和灵活性是最重要的。服务网格是为适应现代分布式应用程序而设计的。但是底层的技术如入口控制器,负载均衡器,以及代理都和传统单体应用的数据层面的技术相同。在实现服务网格的过程中,组织可以利用到与运营现代、基于软件的应用程序交付基础设施相同的技术与技能。
灵活使用多种云服务。服务网格解决了现代应用的云网络问题。支撑起服务网格的数据平面和控制平面的技术独立于任何特定架构,因此它们可以在无论是裸机,容器还是虚拟机的公有或私有的架构上运行。这种灵活特性甚至允许服务网格处理未来的应用程序架构,从而发挥其规模化、全球复制以及深层性能调节等优势。您的服务网格将成为运作模式化云架构场景下,一切潜在优势的实现保障。
提高对微服务的可见性。分布式系统的指标对于我们而言就像是一个黑盒子,而网格服务为我们提供了一种更深入观察分布式系统的指标的途径。它会随时间收集性能指标,为团队提供服务可用性的长期指标。这为操作员提供了一种观察服务可靠性和性能的方式,使他们能够逐步优化系统。
更高效的运维以及更有效的执行SLA(服务等级协议)。服务网格提供的追踪功能对调试和故障排除至关重要,与此同时,它也确保服务执行了服务等级协议(SLA)。服务网格执行了很多任务,包括执行策略以及追踪查看这些策略是否被满足。它为管理者提供了一个可以在网络层实施云应用管理和策略的场所。
简化微服务实现。服务网格的另一大优点是可以轻松部署它们。过去的解决方案要求开发人员将服务内功能编码到每个微服务中。这需要重写应用程序并在不同的编程语言中维护各种库。而服务网格帮开发人员抽象了这些事务。开发人员可以简单地调用必要的消息传递和服务发现功能就可以轻松的部署它们,而微服务的源码只用包含业务逻辑相关的代码。
加快新服务的上线时间。过去的库解决方案,如Finagle,Hystrix和Stubby,需要开发人员长时间的介入并且迫使开发人员将冗余功能编码到每一个服务中。另一个更简单的方法是在每个微服务中放置一个sidecar代理并将它们连接在一起,这正是服务网格所擅长的,因此未来将会有更多的云应用选择服务网格架构。简而言之,服务网格保证了开发者的生产力,使他们能够更快地将更多的服务推向市场。
保障服务间的通信安全。服务之间通信有可能跨云,跨数据中心,或者跨大陆,而服务网格保障了这些通信的安全,它封装了所有的通信,并且在控制器层面协调这些通信,通过管道内加密,联系人策略和服务权限解决了安全问题。
Kubernetes入门与进阶实战培训
6月22日正式上课,点击阅读原文链接即可报名。