本文讲的是现代企业架构下的微服务【编者的话】微服务架构获得了如此多的关注,大多数的企业IT从业者也正好奇它是如何影响其他的架构模式的:比如企业集成和API管理。
本篇博文的目的是提供一个视角: 在我们引入了微服务架构到企业中以后,现代的企业机构会看起来是什么样子。(如果你对微服务架构还很陌生的话,参阅我的前一篇 博文 。)
关于微服务如何适用到总体的IT版图的讨论, 我以解读Gartner关于微服务的报告来开始。
微服务架构,本质上是消除了很多的复杂性,包括设计的,开发的,部署的,以及跨服务/系统通讯的。
当时,复杂性虽然从微服务层给消除了,去要其他一些的组件/层来满足。例如,因为MSA不推荐使用ESB来做中央总线,所有原来由ESB做的工作,例如服务编排,不同系统间的路由和集成需要被其他的组件来完成,包括微服务本身。
事实上,最终的企业架构是内部和外部架构的合体,也就是现代的基于微服务的企业IT架构。
图 1.1 带有微服务,企业级集成和API管理的现代企业架构
图1.1 展示了一个高层次的现代企业IT架构总览。这里你可以看到我们使用了一个包含有微服务和现存系统的混合架构。这与Gartner所展现的内部外部架构模型类似。
当你将MSA引入到你的组织中时,以下的关键设计决策是你需要采用的:
现在我们近距离看一下微服务层,看看他们如何与现实场景中的服务交互。
事实上,微服务架构注重针对有限的一个特定的业务范围来构建微服务。因此当提到基于MSA来构建IT解决方案, 则不避免的需要甬道已经存在的微服务。微服务之间的交互可以使用传统的点对点的方式,但是这种方式有点脆弱。因此我们需要坚持一些微服务集成的最佳实践。
现在我们来看看微服务交互方面的技术细节。
图 1.2 微服务层实现的服务编排
例如, 图1.2描绘了一个场景,我们有ABCD四个微服务。现在我们要实现一个新的业务功能,需要顺序的调用A和C, 然后提供一个汇总后的回复。我们可以针对这个需求来创建一个新的微服务(微服务E),它的编排逻辑包含依次调用A和C。所有的微服务调用通过网关完成。如果微服务E需要单独扩展,则可以扩展E, 必须的时候扩展A和C。
图 1.3 网关层实现的服务编排
如图1.3,某个服务调用A和C,它可以在网关层里面来实现(大多数的微服务网关都支持这个特性)。
得上需要扩展这个新的业务功能时,我们必须要扩展网关,微服务A和C。这种情况下,网关有点变成了单体应用因为它也负责路由其他的微服务请求。
本篇博文的目的是提供一个视角: 在我们引入了微服务架构到企业中以后,现代的企业机构会看起来是什么样子。(如果你对微服务架构还很陌生的话,参阅我的前一篇 博文 。)
关于微服务如何适用到总体的IT版图的讨论, 我以解读Gartner关于微服务的报告来开始。
微服务架构,本质上是消除了很多的复杂性,包括设计的,开发的,部署的,以及跨服务/系统通讯的。
当时,复杂性虽然从微服务层给消除了,去要其他一些的组件/层来满足。例如,因为MSA不推荐使用ESB来做中央总线,所有原来由ESB做的工作,例如服务编排,不同系统间的路由和集成需要被其他的组件来完成,包括微服务本身。
内部和外部架构
为了在真实的IT解决方案中使用MSA,我们需要满足以上提到的两种需求。 Gartner建议 MSA有2种不同的架构域。- 内部架构: 不太复杂的纯微服务组件都归类到‘内部架构’下;
- 外部架构: 交付围绕微服务构建一个解决方案所需的平台能力。
事实上,最终的企业架构是内部和外部架构的合体,也就是现代的基于微服务的企业IT架构。
带有微服务的现代企业架构
微服务架构鼓励企业将所有IT解决方案以微服务的方式构建而不使用任何中间集成产品,例如ESB。但是,除非是你白手起家,没有任何内部私有的遗留系统,否则这就是不切实际的方案。在一个大型的组织或者企业中,你不可能简单的将所有的软件系统,服务以及方案都转化为微服务。但是这样的组织希望使用微服务架构来构建敏捷可扩展的软件方案。因此,我们真正需要的是一个微服务与传统已经存在的单体架构系统的混合体。图 1.1 带有微服务,企业级集成和API管理的现代企业架构
图1.1 展示了一个高层次的现代企业IT架构总览。这里你可以看到我们使用了一个包含有微服务和现存系统的混合架构。这与Gartner所展现的内部外部架构模型类似。
当你将MSA引入到你的组织中时,以下的关键设计决策是你需要采用的:
- 当任何有需要的时候都使用微服务架构来构建解决方案,试着或者MSA带来的所有好处。
- 企业集成仍然需要:因为我们需要一个混合方案,你仍然需要使用ESB这样的集成软件给所有的内部系统和服务做集成。
- 你不能舍弃大多数现存的系统,但是新的微服务可能需要调用这样的单体系统来满足不同的业务需求。在这种场景下, 你可以使用底层的集成软件/ESB,微服务可以调用集成服务器来连接到不同的系统。
- “新”的ESB: 虽然类似于ESB这样的集成软件对于现代企业架构可能仍然是需要的,但是这种工具再也不能当作中央总线了。组织应该寻求轻量级的高性能的可扩展的集成软件来取代这些笨重的集成框架。
- API管理: 微服务可以通过网关来暴露,所有的API管理技术都在这一层来实现。 所有其他的需求,例如安全,阀门,缓存,计费,监控要在网关层完成。非微服务架构的服务(传统的SOA服务)也可以通过API网关来暴露。
现在我们近距离看一下微服务层,看看他们如何与现实场景中的服务交互。
集成微服务
在微服务领域经常被问到的问题是“微服务能够互相通讯吗?” 或者“如何利用已有的微服务来构建新的微服务?“事实上,微服务架构注重针对有限的一个特定的业务范围来构建微服务。因此当提到基于MSA来构建IT解决方案, 则不避免的需要甬道已经存在的微服务。微服务之间的交互可以使用传统的点对点的方式,但是这种方式有点脆弱。因此我们需要坚持一些微服务集成的最佳实践。
- 使用一个网关来暴露微服务:在所有的微服务之间放置网关,所有的客户仅仅能通过网关来使用微服务。
- 微服务之间无直接调用: 微服务不能直接调用其他的微服务。所有的调用必须通过网关。
现在我们来看看微服务交互方面的技术细节。
微服务层的编排
当你需要调用多个微服务来实现一个业务需求时,你可以构建另一个微服务(这也是关注一个特定的业务领域),它会组合对所有需要的微服务的调用,汇总最终的响应并发回到原始客户手里。图 1.2 微服务层实现的服务编排
例如, 图1.2描绘了一个场景,我们有ABCD四个微服务。现在我们要实现一个新的业务功能,需要顺序的调用A和C, 然后提供一个汇总后的回复。我们可以针对这个需求来创建一个新的微服务(微服务E),它的编排逻辑包含依次调用A和C。所有的微服务调用通过网关完成。如果微服务E需要单独扩展,则可以扩展E, 必须的时候扩展A和C。
网关层的编排
实现相同业务场景的另一个实现方式是将编排逻辑引入到网关层。在这种情况下,我们不需要引入一个新的微服务,但是网关上的虚拟服务层要负责编排工作。图 1.3 网关层实现的服务编排
如图1.3,某个服务调用A和C,它可以在网关层里面来实现(大多数的微服务网关都支持这个特性)。
得上需要扩展这个新的业务功能时,我们必须要扩展网关,微服务A和C。这种情况下,网关有点变成了单体应用因为它也负责路由其他的微服务请求。
Choreography风格
另一个实现微服务交互的可能方式是使用异步消息方式,例如MQTT、Kafka。在这种场景下没有中央组件负责服务交互。服务交互使用基于消息的发布订阅方式。结论
到此,关于如何在现代企业IT版图中使用微服务架构(MSA),我们可以有如下总结:- 微服务不能包治百病:它不可能解决所有企业IT的需要。因此我们扔需要将它与现有的架构一起使用。
- 大多数企业都不能将他们所有的企业IT系统都转化为微服务。实际上,他们会使用微服务架构去解决某些应用场景的需求,从而充分利用微服务的优势。
- 企业集成不会消失。这意味着你需要一个集成软件如ESB来满足你所有的企业集成需求。
- 所有的业务功能需要通过API管理技术暴露为API。
- 微服务之间的交互要通过网关来支持。
- 微服务之间的服务编排对某些业务场景是必须的,可以通过在一个新的微服务内或者在网关层来实现编排工作。
原文链接:Microservices in Modern Enterprise Architecture(翻译:姚洪)
原文发布时间为:2016-08-24
本文作者:姚洪
本文来自云栖社区合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。
原文标题:现代企业架构下的微服务