微信二维码

二维码 扫二维码马上关注
扫码咨询
什么是混合微服务平台

许多企业都同时使用单片和微服务体系结构来满足他们的IT需求。每种体系结构都有自己的优点和挑战,但是没有一种体系结构为现代IT挑战提供全面的解决方案,这些解决方案要求高性能,同时又不损害微服务提供的解耦性和灵活性。在这篇文章中,我们将讨论持久性技术的发展,微服务相对于整体架构的优缺点,以及为什么混合微服务平台是一条道路。

持久性技术的发展

存储容量的发展和高端瞬态处理引擎(包括高速缓存和RAM)的增加,将我们带入了内存计算(in - memory Computing, IMC)时代。IMC的黄金时代包括低延迟分布式微服务(LLDM)的发展。

如今,技术之间的界限并不十分清晰。有时您会发现自己在一个项目中使用多种技术,比如RDBMS、NoSQL、缓存技术、IMDG等等。

RDBMS足够简单,可以理解,而NoSQL还在试图找出它在数据世界中的位置,文档(如MongoDB)、键值(如Coherence、Gemfire、Hazelcast、Gridgain等)、列(如Vertica、ActivePivot等)和图(如Neo4J)在许多不同的项目中使用,有时还同时使用。

最后,缓存技术,如Memcached和IMDGs,在过去十年中已经出现。它们帮助解决了其他存储卷无法处理的性能挑战。

这些技术的缺点是它们带来了新的挑战。

其中一个挑战是最终一致性,这是分布式计算中用于实现高可用性的一致性模型。它非正式地保证,如果没有对给定数据项进行新的更新,最终对该项的所有访问都将返回最后更新的值。这个模型的问题是,许多系统需要一个始终一致的模型,因为数据总是需要显示最近的值。如果我们以一个银行账户为例,我们不能在某个不一致的解决方案上构建系统。

非事务性平台(例如Cassandra)的缺点是,尽管可以通过在集群中线性扩展数据来避免共享资源的锁定(确保可用性),但这是以一致性为代价的。

理解了这一点,就清楚了为什么我们需要一种新的分布式服务平台来实现聚合的微服务体系结构。

微服务vs.整体架构

单片和微服务的范围很广——主要的挑战是只使用它们各自的优良品质。乍一看,使用光谱一端的元素而不放弃其他元素似乎是不可能的,但事实果真如此吗?

庞然大物回顾

为了理解我们的方向,我们需要看看当今商业世界中使用的常见实践。看看一些比较保守的垂直领域,如金融服务、电信、医疗保健和电子商务,我们看到一种模式,由于它们的优势,它们不愿偏离传统的整体架构。

单体利弊

优点:

经典的单片架构提供了更好的性能和强耦合。

减少对第三方或其他部门服务的依赖。

完全控制您的应用程序。

缺点:

没有快速部署或可伸缩性的灵活性。

没有一种简单的方法可以让它高度可用。

几乎不可能隔离、划分或解耦系统功能。

Microservices回顾

微服务包括许多方面,其中之一是将服务解耦为具有通用api和技术的较小组件的能力,其中每个服务都是隔离的,并包含独立部署和分散操作所需的整个堆栈。要扩展这个概念,请参阅Martin Fowler关于微服务的精彩文章。

微服务的利弊

优点:

分区和解耦:允许您动态地按需伸缩。

敏捷方法:允许您轻松地对代码进行更改,并运行测试,以确保一切正常运行。每个服务都是分开的,因此您可以在每次迭代中更改多个服务(不像单片应用程序,所有东西都捆绑在一起,包括测试)。

缺点:

粒度控制。

进程间和不安全的分布式通信机制。

处理部分故障——没有事务安全性(最终一致性)。

更新由不同服务拥有的多个数据库(polyglot持久性缺陷)。

多个api。

重构可能相当困难。

服务发现(电话簿服务)。

HTTP、反序列化和网络开销对性能的影响。

实现和维护高可用性并非易事。

下一步:混合方法才是正确的选择

对于需要可伸缩性的系统(比如物联网)来说,一个完整的整体方法已经不够了。此外,完整的微服务方法对于性能或管理服务的生命周期都不是很好。

我们将下一个逻辑步骤视为一种混合方法——利用微服务的所有优势的整体性能,同时展望HTAP的未来,以便真正利用数据和事件驱动的体系结构。这正是我们要去的地方。

实现高性能分布式微服务的完美平台

XAP平台不是一个整体;这是一种可互操作的方法,最终实现了如何管理我们在每个大型企业中都看到的失控的服务动物园。面向服务的体系结构、事件驱动的体系结构,最重要的是数据驱动的设计,这些都是当今的热门话题。考虑到市场上有通用的体系结构、拓扑和解决方案平台,我们需要问自己,我们如何构建最高效、最经济和高性能的系统来处理日益增长的实时挑战?

XAP微服务平台是将整体方法的优点与微服务的所有优点结合起来的唯一方法。XAP是一个低延迟的分布式微服务平台,由一组机器组成,这些机器一起工作,创建一个弹性的共享数据结构,用于低延迟数据访问和极端事务处理。尽管它运行在一组机器上,实现分布式的类似于服务的处理任务和数据分区,但底层基础设施只是一个平台。从外部看,它似乎是一个整体平台,但它肯定不是。

使用XAP的微服务解决方案的原因

1. 粒度控制:使用小粒度组件构建微服务是一件麻烦的事情,是管理上的噩梦,也是性能上的禁忌。XAP的微服务分布式平台是一种不妥协的方法,在此方法中可以解耦服务并同时提高性能。

2. 消除了不同进程之间的通信需求:通过解决第一个问题粒度控制,我们实际上已经解决了许多开箱即用的问题。虽然跨分区查询仍然可以实现不同进程之间的通信,但是一旦逻辑、消息传递和(相关的)数据耦合在一起,就不再需要这些进程之间的通信了。

3.数据库/远程站点的完全一致性:最终一致性是大多数系统的一个重大设计缺陷,需要数据的准确性和一致性。一致性是通过平台的所有级别来维护的。如果需要,事务可以跨多个分区、多个数据类型(客户、产品等)和跨不同站点的多个平台。事务可以从客户端开始,在服务器端使用一些配置逻辑继续,如果需要,可以在客户端结束。由于XAP充当记录系统(应用程序数据结构),它必须支持ACID事务,包括数据库持久性和远程站点复制原子性。

所有分散在多个节点上的分布式事务项都作为一个单元传输到数据库或远程站点,以确保数据库/远程站点完全一致。

4. 异步地更新多个存储卷:对于为提高性能而构建的关键系统来说,拥有一个能够支持服务和数据的平台是非常必要的。支付处理、交易、物联网、客户360、旅客住宿、医疗管理等尽管必须具有很强的一致性,但是为了持久性或者第三方应用程序只能使用特定的存储卷,我们经常看到需要将数据复制到存储卷。XAP可以异步地更新各种常用的开箱即用存储卷,对于任何希望将此功能集成到其微服务体系结构中的开发人员来说,这样的任务都是轻而易举的。

5. 性能影响:微服务平台需要支持以下混合云架构作为服务:IMDG、分析、计算网格、缓存和复制。只有XAP微服务体系结构能够在一个平台上处理所有上述问题,方法是使用一种称为底层部署单元(deployment unit, DU)或处理单元(processing unit, PU)的独特机制。XAP PU是可伸缩性和故障转移的单元。PU同时支持Java和。net。它包括用户希望在公共生命周期中拥有的工件的定义。这些可能有一些依赖性。对于基于java的PU,这种依赖关系将通过Spring IoC进行描述。XAP允许您将多个独立的cpu部署到同一个网格中,或者部署具有一些相互依赖关系的cpu组合。在这种情况下,XAP将编排PUs供应,使其具有正确的部署、修复和伸缩顺序。

6. 编制、可视化以及其他:无论您选择哪种编制工具,XAP都是底层用作微服务平台的确切层。它可以将数据、逻辑和消息组合在一起,以获得极高的性能,同时还可以解耦网格中的分布式封装服务。虽然这听起来很复杂,但网格完成了大部分工作,即使不是所有的微服务缺点,也解决了大部分问题。使用任何云或VM/Openshift/Kubernetes/Docker解决了一半难题,而附加XAP微服务平台则是另一半。

跨行业垂直领域实现面向微服务的系统需要特别注意性能和可伸缩性。如果依赖缓存、数据库和消息传递系统作为数据状态管理和传输结构,那么几乎不可能实现实时微服务体系结构。

使用XAP,该平台支持实时微服务的交付,这些服务可以在现有的Iaas/PaaS中作为一流公民运行,交付具有成本效益的、敏捷的、事件驱动的、永不失败的应用程序。

最终的想法

我们已经看到,对于复杂的企业系统来说,完全的单片或微服务方法都不够。然而,由于性能损失的代价很高,大多数企业仍然不愿意将其核心的单片系统退役。然而,XAP向完全可用的企业微服务数据结构的转变(同时又具有分布式、安全性和高可用性)可能会带来很大的不同。与云原生方法一起,我们的混合解决方案提供了强一致性、高可用性、分布式、可伸缩、封装的服务部署基础设施。

更多精彩内容,请关注元吉优惠券网:专注阿里云代金券阿里云服务器报价腾讯云代金券的免费更新领取!
更多精彩内容推荐:

使用MicroProfile和Kubernetes配置微服务
有关微服务中的共享数据库问题
阿里云云虚拟主机
怎样利用阿里云云虚拟主机建站
阿里云常见问题合集二
阿里云云服务器ECS、独享云虚拟主机、共享云虚拟主机


在线客服
热线电话

扫一扫 微信加好友