为什么我们需要一个新的混合微服务平台
本文还是一篇翻译，介绍单体架构和微服务架构的关系，并且认为一下代的企业软件架构必然是一种混合架构，文中重点在说为什么，但是没有去介绍怎么实现，也介绍了他所谓的XAP平台，但是这个平台我在公网搜不到什么信息。
对于混合架构作为企业的下一代架构模式，我认为一定是这样，针对目前公司内的很多系统介绍都说自己是微服务架构，好像不说自己是微服务就是落后了，而事实上公司内很多系统在体量上都没有那么大，更谈不上什么企业级架构。所以这类系统就要看什么样的架构合适就来什么，兼顾人力和系统实际需求来设计架构。很多内部系统和服务单体架构也未尝不可，或者简单的单体架构+一点点微服务支持也足够。系统设计要有可扩展性，但是必须避免过度设计。
同样对于混合架构我也是这种看法，目前没有看到具体的实现，但是系统架构必须也业务高度相关，如果离开业务谈架构，必然是空谈。一种架构无法在性能，可扩展性，通用型上都能胜任。
作者是：Tal Doron
原文链接：https://dzone.com/articles/why-we-need-a-new-breed-of-hybrid-microservices-pl
很多企业都是同时使用单体架构和微服务架构来满足IT需求。每个架构都有它自己的优势和不足点，但是2种架构都没有为现代的IT调整提供全面的解决方案：需要高性能，而且不影响微服务的服务解偶和灵活性。在这篇文章中，我们会讨论持续演进的技术，微服务和当天架构的优缺点，以及为什么混合微服务才是最佳选择。
技术的基础演进
存储容量的演进和高端瞬时处理引擎的增强，包括缓存和RAM，这些都把我们带入了内存计算（IMC）时代。内存计算的黄金时代包含了低延时分布式微服务的发展（LLDM）。
最近，技术之间的边界越来越模糊，有时候你会发现你在一个项目中使用了多种技术，比如RDBMS，NoSQL，缓存技术，IMDG（In-memory Data Grids），或者更多其它技术。
RDBMS是很容易理解的，而NoSQL还在试图找寻在数据领域内的位置，在很对项目中使用的包括文档管理（比如MongoDB），Key-Value存储（比如Coherence，Gemfire，Hazelcast，Gridgain），列存储（比如Vertica，ActivePivot）和图存储（比如Neo4J），有时候也结合多个组件来使用。
最后，缓存技术，比如像Memcached和IMDG这类的，是过去10年就有了技术。这些技术帮助解决了存储卷技术无法处理的性能挑战。
这些技术的负面问题是他们引入了新的挑战
其中一个挑战就是最终一致性问题，在分布式计算中使用一致性模型来实现高可用。它非正式的保证，如果没有对一个数据进行新的更新，那么最终所有的访问者对这个数据的访问都是获取到它最后一次的更新值。这个模型的问题是很多系统都需要一个永远一致性模型，因为数据永远都要反应最近的值。如果我们以银行账户为例来说明，我们是不能在一个某种程度上不一致的方案上构建银行系统。
非事务平台（比如Cassandra）的缺点是：虽然它可以通过在集群内（确保集群可用）串行扩展数据而避免对共享资源枷锁，但是以一致性为代价的。
理解了这些我们就明白，我们为什么需要一个新的分布式服务平台来构建聚合的微服务架构。
微服务架构对比单体架构
单体架构和微服务架构的方位是非常广泛的-主要挑战是如何只使用每个架构的好的性质。粗看，好像两者之间只能挑选一个，但真是这样吗？
单体架构概述
为了理解我们所说的，我们要看一下现在业务中使用的一般做法。看一些保守的垂直领域比如金融服务，电信，医疗保健和电子商务，我们看到他们因为单体架构的优点而不愿放弃老的单体架构。
单体架构的优势和缺陷
Pros:
- 经典的单体架构提供了较好的性能和强关联
- 较少依赖第三方或者其它部门的服务
- 对应用的完全控制性比较强
Cons:
- 对快速发布和扩缩容不够敏捷
- 要做到高可用比较复杂
- 几乎难做到服务隔离、分割或者做到系统功能级别的隔离
微服务总结
微服务有很多特点，其中之一是：可以把服务划分为有普通API和技术的更小组件，每个服务都是独立的，并且包含了需要的独立部署和去中性化操作技术能力。要看更多这方面的内容，可以看这篇文章： Martin Fowler’s fantastic article on microservices.
微服务的优缺点
Pros:
- 切分和隔离：可以让你根据需要进行动态调整服务容量
- 敏捷开发：让你容易修改代码，运行测试来保证运行流程。每个服务都是隔离的所以你可以一次改动1个或者多个服务（不像单体服务，所有的东西都是打包在一起，包括测试）
Cons:
- 控制粒度比较小
- 需要内部处理和不安全的分布式通行机制
- 处理部分失败 — 没有事务安全（最终一致性）
- 更新不同服务的多个数据库（多语言问题）
- 多个API
- 难以低成本的重构
- 服务发现（名字服务）
- 因为HTTP，序列化，反序列化和网络负载导致的性能影响
- 实现和维持高可用不容易
下一步：混合架构是一种可行方式
完全的单体架构对需要扩缩容能力的系统来说就不太行了，比如IoT。同样完全微服务架构对于性能和服务生命周期管理就很不友好了。
下一步合乎逻辑的方式就是混合胶骨 — 利用单体架构的性能和所有微服务的优势，同时期待HTAP未来能真正使用数据和事件驱动架构。也是我们要着手的方向
实现高性能分布式微服务的完美平台
XAP平台不是一个单体服务。它是一个能较好的管理企业中越来越失控的服务族群。面向服务的架构，事件驱动架构，还有数据驱动设计都是现在非常热的话题。看看市面上那些通用的架构，拓扑结构和解决方案平台，我们要问问我们自己，我们如何建立最高效，最具成本收益和高性能的系统来面对日益增长的实时任务挑战。
XAP微服务平台是组合单体架构并且具有所有微服务优势的唯一方法。XAP是低延时的分布式微服务平台，由一个机器集群构成为低延时数据访问和极端事务处理来创建一个弹性数据共享数据结构。
6个使用XAP微服务方案的原因
1.粒度控制：使用小粒度的组件来构建微服务是有问题的，有服务管理的噩梦，还有性能问题。XAP的微服务分布式平台是一个较好的实现，它即隔离了服务又提升了性能。
2.消除了不同进程间通行的必要：通过解决第一个问题，粒度控制，我们实际上就解决了很多问题。虽然任然有可能有跨区请求，但是一旦逻辑，消息传递和相关数据组合到一起，那么不同进程间的通信已经不再需要了。
3.数据库和远程站点的完全一致性：最终一致性是大多数需要数据准确一致的系统设计上的缺陷。一致性需要平台的所有层级都能支持。事务被拆分为多个部分，多种数据类型（比如消费者，生产者），并且如果有必要还要跨越多个站点的多平台。一个事务可能从客户端开始，在服务端执行相关逻辑，并在客户端按需结束。因为XAP作为一个记录系统（应用程序数据组织），它就必须支持ACID事务，包裹数据库持久化和远程站点的原子复制。
所有可能在多个节点间传播的分布式事务项都被发送到数据库或者远程站点，它作为一个单元包保证数据和远程站点的完全一致性。
4.异步更新多数据卷：对于实现高性能的关键系统来说，有一个能支持服务和数据的平台是非常必要的。比如支付处理，交易，物联网，消费360，旅店出租，医疗管理等。虽然强一致性是必须的，我们也常常看到需要把数据存储到存储卷中以实现持久化或者因为第三方应用只能使用特定的存储卷。XAP可以异步更新多种通用存储卷，开发这样一个任务对任何想把这个功能集成到他们的微服务架构中是非常轻松的。
5.性能影响：一个微服务平台需要把支持下面的混合云架构作为一个服务：IMDG，Analytics，Compute Grid，Replication。只有XAP微服务架构能够可以在一个平台中支持上面的服务，它采用的是一个独特的机制：在系统中使用一种叫做部署单元或者处理单元。XAP的处理单元是用于处理扩展和容错的。处理单元支持Java和.NET。它包含了用户希望在公共生命周期的定义方法。或许会有一些依赖。对于基于Java的处理单元，这种依赖通过Spring的IoC来面熟。XAP可以在一个相同的网络中部署多个独立的处理单元或者部署一个有内部依赖的处理单元组。在这个例子中，XAP会组织编排处理单元做到正确的部署，回复和扩展顺序。
6.组织编排，可视化和其它：无论选择哪种编排工具，XAP都是微服务平台下面最底层。它可以为高性能实现来合理组织数据、逻辑、和消息传输，同样也可以使用网格来隔离不同的服务。听起来很复杂，网格也不能解决微服务的所有缺陷。使用任何云和VM/Openshift/Kubernetes/Docker解决一半的问题，另外一半可以有XAP微服务平台解决。
跨行业垂直实现一个微服务架构的系统需要特别注意性能和可扩展性。如果你依赖于缓存，数据和消息传输系统来作为你的数据状态管理和传输组织，那么实现一个实时微服务架构几乎是不可能的。
使用XAP，它驱动交付实时微服务系统，这样的系统可以直接在你已有的IaaS/PaaS上运行，并且实现经济高效，敏捷和事件驱动的应用，这些应用永不失败。
总结
我们看到既不是完全单体架构或者是完全微服务架构都不能支持复杂的企业系统。然而，很多企业任然因为高性能损失而不愿意舍弃他们的单体系统。XAP提供了完全可用的企业微服务数据组织，并且是分布式，安全和高可用，这可以让一切不一样。结合本地云实现，我们的混合解决方案实现了强一致性，高可用，分布式，可扩展，封装了部署基础设施的服务。
看完本文有收获？请分享给更多人
关注「黑光技术」加星标，关注大数据+微服务
