技术开发 频道

危言耸听?红帽呼吁企业莫盲目用微服务

  【IT168 评论】引用红帽高级经理John Frizelle的话来说,大家对于微服务器的讨论就好像青少年谈恋爱一样“你不知道你接下来要做什么,但你就是想谈”。

危言耸听?红帽呼吁企业莫盲目用微服务

  微服务和一些架构确实在企业的应用灵活性和维护方面提供了一些好处,但如果你盲目地进入这个领域,很可能会增加IT组织的复杂性,从而带来比单纯应用微服务更高的挑战性。

  日前在波士顿举行的红帽峰会上,Frizelle列出了企业在迈向微服务架构时面临的八大挑战。

  第一是建立微服务。当构建一个服务时,很可能需要触发其他构建。所以他说,重要的是确定服务之间的依赖关系。从更广泛的业务角度来看,重要的是要知道哪些服务构成了一个版本,以保证你可以为客户持续提供价值。

  第二个挑战是测试。对于单元测试,测试微服务和测试单片应用程序是一样的,这里也需要考虑依赖关系。但为了测试微服务,必须围绕该服务划分边界,否则可能不仅仅是确认服务到底做了什么。Frizelle表示,在测试服务之前stand up服务,为了测试端到端系统,stand up整个系统很重要,只有这样才可以确定问题的根本原因。他解释道,服务D失败可能是由于服务改变而导致的。

危言耸听?红帽呼吁企业莫盲目用微服务

  第三个挑战是版本控制。Frizelle建议对公共API和内部微服务的API进行版本控制。当版本控制到位时,更重要的是考虑更新。他表示,如果更新一个有依赖关系的服务,必须弄清楚如何保持向后兼容性。解决这个问题的一个方法是为不同的客户端创建多个版本的服务,但这可能会导致管理问题。 如果有250个服务,每个服务有三个版本,以适应不同的客户端,实际上就需要管理750个服务。

  第四个挑战是部署。在具有大量服务的系统中,需要更多的自动化。他认为,当人们在使用复杂系统时,会引入很多人为错误。使用微服务,重要的是确定如何以及何时推出服务,以及依赖顺序。他建议尝试blue-green部署,10%的用户获得新版本,90%的用户获得旧版本。这种部署方式方便前后版本对比,并可以随时选择回滚。

  记录、监视、调试和连接方面还面临许多问题,Frizelle指出,在记录方面,不集中管理是不可能的,您需要将所有服务的日志整合在一起,以获得所发生情况的统一视图。这样做的一种方法是使用全局请求ID,该ID随着请求跨越各种服务。管理员可以简单地将请求ID放入控制台,以便记录服务的活动。

  监控方面,Frizelle表示可以考虑分布式请求跟踪。如果服务速度很慢或者没有响应,您需要从系统层面了解遇到了什么瓶颈,发生的地方以及原因。

  在具有数百种服务的大型系统中,远程调试不是一个很好的选择,因为您不能一次连接到数百个服务,尽管说工具正在不断发展。企业应该查看哪些特定的服务是最关键的,并且对这些服务使用远程调试。

  微服务的一个基本原则是每个服务都独立运行。如果是这样,他们如何彼此连接呢?如果你不想硬编码URL来查找服务,建议使用etcd,一个集中式的服务发现解决方案。

  确保应用程序正常工作的另一种方式是使用断路器,如果响应花费的时间太长,则会断开请求,打开该线程并将其报告给日志以进行修复。

  Frizelle呼吁企业不要盲目采用微服务,使用前要确保明白为什么要做微服务,并且知道怎么做。他说,微服务的转变可能需要敏捷转型。微服务或许并不能消除复杂性,相反可能会带你进入另一个坑。

0
相关文章