微服务

什么是微服务?

微服务是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案,可将应用拆分成多个核心功能。每个功能都被称为一项服务,可以单独构建和部署,这意味着各项服务在工作(和出现故障)时不会相互影响。

请回想一下您上次在线购物时的情景。您应该使用了网站上的搜索栏来浏览产品。这个搜索功能就是一项服务。您可能也看到了相关产品推荐,这些推荐项均来自顾客偏好数据库。而这也是一项服务。您有将商品添加到在线购物车中吗?没错,这又是另一项服务。

所以说,微服务就是应用的各项核心功能,而且这些服务均可独立运行。但是,微服务架构不只是应用核心功能间的这种松散耦合,它还涉及重组开发团队、涉及如何进行服务间通信以应对不可避免的故障、满足未来的可扩展性并实现新的功能集成

那么这该如何实现呢?只需对面向服务的架构(SOA)的基础稍加调整,即可部署微服务。


这种模式我们并不陌生……

觉得“将应用拆分为多个核心功能,以免受困于单体式结构陷阱”这种做法很耳熟?这是因为微服务架构模式与面向服务的架构(SOA)类似,而 SOA 已经是一种非常成熟的软件设计模式。

早期在开发应用时,即使要对现有应用做很小的改动,也需要对整个版本及其质量保证(QA)周期进行批量式更新,而这很可能会影响很许多子团队的工作推进速度。这种方案常被称为“单体式”,因为整个应用的源代码都被构建到了单个部署单元(如 .war 或 .ear)中。如果应用因某个部分的更新而出错,则整个应用都要下线,然后缩减,再加以修复。虽然这种方案如今仍适用于小型应用,但是众多正在成长中的企业无法承受停机所带来的影响。

改用面向服务的架构后,应用被构建为可重复使用的离散型服务,这些服务会通过企业服务总线(ESB)进行通信。采用这种架构时,各项服务会分别围绕特定的业务流程来规划,并会遵循相应的通信协议(如 SOAPActiveMQApache Thrift)通过 ESB 进行共享。在通过 ESB 集成后,这套服务就可以形成一个完整的应用。

一方面,这种架构方式使得各项服务可以同时构建、测试和调整,不会再受限于单体式开发周期。另一方面,虽然使用 ESB 意味着整个系统只会出现单点故障,但在某种程度上,消除单体式结构只会形成新的故障点:即 ESB 本身,因此它可能会成为整个企业的瓶颈所在。


从 SOA 到微服务

有何区别?微服务可以相互通信,而且这种通信通常都是无状态的,所以采用这种方式构建的应用容错性更高,对于单个 ESB 的依赖性也更低。由于微服务可以通过与语言无关的应用编程接口(API)进行通信,开发团队也可以自行选用所需工具。

纵观 SOA 的整个历史,我们不能说微服务是一个全新的概念。但是,得益于容器化技术的不断改进,微服务的可行性也越来越高。现在,您可以借助 Linux 容器在同一硬件上单独运行一个应用的多个部分,还能更好地控制每个部分及其生命周期。与 API 和 DevOps 团队一样,容器化微服务也是云原生应用的重要基础。


微服务架构的优势

微服务可通过分布式部署,大幅提升您的团队和日常工作效率。您还可以并行开发多个微服务。这意味着更多开发人员可以同时开发同一个应用,进而缩短开发所需的时间。

加速做好面市准备

由于开发周期缩短,微服务架构有助于实现更加敏捷的部署和更新。

高度可扩展

随着某些服务的不断扩展,您可以跨多个服务器和基础架构进行部署,充分满足自身需求。

出色的弹性

只要确保正确构建,这些独立的服务就不会彼此影响。这意味着,一个服务出现故障不会导致整个应用下线,这一点与单体式应用模型不同。

易于部署

相对于传统的单体式应用,基于微服务的应用更加模块化且小巧,所以您无需为它们的部署操心。虽然对部署时的协作要求更高,但之后能获得巨大回报。

易于访问

由于大型应用被拆分成了多个小型服务,所以开发人员能够更加轻松地理解、更新和增强这些服务,从而缩短开发周期(尤其是在搭配使用敏捷的开发方法时)。

更加开放

由于使用了多语言 API,所以开发人员可以根据需要实现的功能,自由选用最适合的语言和技术。


所面临的挑战

如果您的企业正在考虑迁移到微服务架构,那么不仅是应用要变,相关人员的工作方式也会随之而变。在某种意义上,改变企业和文化并不容易,因为每个团队都有自己的部署节奏和所负责的服务,而且这些服务都拥有自己的客户群。这些可能并不是开发人员通常要担心的问题,但是这些问题却决定了微服务架构能否取得成功。

除了文化和流程之外,复杂性和效率问题是基于微服务的架构所面临的另外两大挑战。红帽移动部平台架构师 John Frizelle 在他 2017 年红帽峰会演讲中提到了以下八类挑战:

  1. 构建:您必须花时间明确各个服务间的依赖关系。要知道,由于存在这些依赖关系,当您完成一个构建时,可能会触发多个其他构建。您还需要考虑微服务对于数据的影响
  2. 测试:集成测试和端到端测试可能会前所未有的难以实施,但却更加重要。根据您在架构相互支撑的服务时所采用的不同方式,架构中的一个部分出现故障,很可能会导致其他部分也随之出现故障。
  3. 版本管理:在更新到新版本时,请记住:向后兼容性可能会因更新操作而失效。要解决这一问题,您可以利用条件逻辑来进行构建,但是构建会变得繁复、难以控制且快速。或者,您也可以为不同的客户端维护多个活跃版本,但是相关的维护和管理工作会变得更加庞杂。
  4. 部署:没错,这也是一大挑战,至少是首次设置时所要面临的一大挑战。为了简化部署,您必须先大量投资自动化,因为人工部署无法应对微服务的复杂性。请好好思考您要以何种方式以及怎样的顺序来部署各项服务。
  5. 日志记录:使用分布式系统时,您需要利用集中式日志将所有相关信息集中到一处。否则,积累的日志数量将让您难以招架。
  6. 监控:您必须通过一个集中式视图来了解整个系统的情况,以便找出问题的根源。
  7. 调试:无法进行远程调试,因为这种方式无法涵盖数十个或数百个服务。不幸的是,关于应该如何进行调试,目前还没有标准答案。
  8. 连接:请考虑使用服务探索功能,无论是集中式的还是集成式。

一同探索微服务的巨大潜力