用于管理复杂微服务架构的技术

在2016年的OSCON和软件架构会议上,有三分之一的公共报告是关于微服务的。最多的抱怨是,管理一大堆微服务已经变成了一场噩梦。在本文中,您将找到有效管理微服务的有用技术。web

 

几年来,微服务被认为是伟大想法,随着微服务的愈来愈多地实施,微服务的一些障碍暴露出来,许多问题须要被明确:数据库

若是你将一个系统分红300个微服务,你将:安全

 

如何把它们链接起来?您会使用API、共享数据库、消息总线或其余的集成方法组合吗?服务器

如何肯定系统集成方案?是取决于特定微服务的需求吗?架构

如何管理数百个微服务之间的全部链接?异步

如何管理数百个web服务、API服务和数据库的基础设施?分布式

最终, 如何使用微服务架构,却有不失去对系统的控制?微服务

 

选择正确的工具对于回答这些问题是一种捷径。下面是推荐一些用于微服务架构的工具:工具

 

尽可能使用容器

容器是微服务的天然选择。对于微服务架构,您必须使用容器化,没有任何选择。Docker是最受欢迎的容器技术。测试

 

容器使您可以建立一个完整的自动化交付管道,在特定的环境中构建和测试新版本,经过建立一个容器实例来替换旧的容器,从而部署一个新的版本。这是快速部署和缩短上市时间的必要条件。

 

使用IaC

不只仅是轻量级的容器使得微服务架构成为可能。基础设施即代码(IaC)做为容器基础的支持技术,更能体现容器技术的价值。容器配置能够被看作一个文本文件。这个特性为旧的开发过程带来了一系列新的有趣的东西,好比:

 

将容器配置文件放入Git或Hg,并使用DVCS管理更改。

查看项目环境的变动历史。

比较环境,例如,比较测试环境和生产环境。

在本地机器上的环境之间轻松切换。

在团队中共享容器(环境)。

在开发人员的笔记本、QA服务器或云实例的生产集群上运行相同的多层应用程序。它与实际状况彻底相同。

 

这一特性,能够被IaC充分使用,从而实现对微服务基础设施的管理。

 

容器编排

容器化是经过脚本自动扩展服务的不可或缺的工具。若是你有一个高负载下的服务,根据实际的负责状况,你须要动态地增长或减小支持该服务的容器的数量。管理容器是一项很是重要的任务,所以我建议使用编排工具。

 

例如,自2016年夏季以来,Docker就有了一种内置的编排工具。此外还有不少其余的编排工具如K8S。

 

无服务器计算

我必须强调无服务器,由于它已经改变了规则。无服务器架构不只补充了 DevOps 的理念,更改进了当前 IT 组织实现更高业务敏捷性的观念,它极有可能改变整个IT的内在文化。使用Azure Function或AWS Lambda来触发操做或事件。这些工具备助于集成管道和消息处理。更为重要的是整个计算堆栈,包括运行功能代码的操做系统,彻底由云提供商管理。与传统的基础架构即服务(IaaS)模型相比,这种方式大大简化了运算基础架构的管理,并结合了按使用进行收费的计费模式,提供了很是灵活且经济的运算选型。

 

API Gateway

若是您将100个微服务直接链接到一块儿,您就会发现控制安全性、分析流量、建立可靠的通道,以及为高负载API调用提供一个弹性基础设施是多么困难。

 

您可使用API网关来避免这些问题,并将API管理集中化。Azure API Management和Amazon API Gateway提供了一个云网关,用于建立、发布、维护、监控和保护API。你的微服务应该只知道API网关,而且只经过这个网关相互链接。

 

更重要的是,API网关有助于传统系统到微服务的迁移。方法是是更改原有系统对API的直接调用,将其改成对API 网关的调用。每一个系统只知道API网关,而不了解网关内的其余子系统。而后,您能够很容易地对老系统进行拆分和更改。

 

企业服务总线

API网关集中管理同步调用,企业服务总线(EnterpriseService Bus,ESB)将实现异步消息传递,以便消息用于内部服务。

 

有时候,在特定的状况下,在ESB和API网关之间进行选择是很是困难的。形成此障碍的缘由是,ESB能够用于同步调用,经过实现两个队列,一个用于传出请求,另外一个用于传入响应。另外一方面,API网关能够经过在两边建立一个等待线程来发送异步调用。因此使用不一样的技术,他们能够相互代替。

 

任何成熟的云平台都提供了可靠且可伸缩的消息总线。例如,AWS有简单的队列服务(SQS),而Azure有Azure Service Bus。而最流行的解决方案是ApacheKafka和RabbitMQ。

 

服务发现

在分布式系统中,服务可能从一台机器转移到另外一台机器上。这意味着当服务移动到具备不一样IP地址的节点时,服务端地址会发生变化。另外若是服务使用动态端口,则可能关联不一样端口。对于服务的这些动态变化,应用程序如何肯定要链接到哪里,才能找到所需的服务。在这种状况下,系统须要一个服务发现解决方案。

 

服务发现提供了如下功能:

l  注册和注销服务

l  检查服务的某一特定实例的健康情况,

l  平衡“发现”服务之间的负载。

 

它包括建立一个服务目录,在该目录中注册服务,而后可以查找并链接到该目录中的服务。当咱们想要使用服务发现时,有三种方案:

l  本身构建服务发现解决方案。

l  使用诸如Consul或 Zookeeper之类的解决方案。

l  云解决方案,如Azure命名服务或AWS应用程序发现服务