通过GeneXus如何快速构建微服务架构

“微服务”是一个非常广泛的话题,在过去几年里,市面上存在着各种不同的定义。

虽然对这种架构方式没有一个非常精确的定义,但仍然有一些概念具有代表性。

微服务有着许多围绕业务能力、自动化部署、终端智能化、分布式数据以及其他与团队相关的一些特性。

为了更好地说明,我们参考了Martin Fowler对微服务简单而具体的定义:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

GeneXus智能软件开发平台,已经能够并将继续支持软件解决方案背后的各种技术架构体系。

要理解什么时候使用微服务架构能够满足业务软件解决方案,首先必须明白微服务架构,并不仅仅是对团队技术层面的一个挑战,同时也是关于开发和交付软件层面的一个全新理念。根据康威定律(Conway’s Law),拥有完整发团队的公司才能构建完整统一的解决方案。

一个公司应该在成熟度较高的时候再采用微服务架构。即使像亚马逊、Facebook、Netflix、Uber等这些公司,也都是在解决了人才和技术等相关扩展性的问题后,才采用了微服务架构。

但不管如何,GeneXus 16以及后续的版本能够比其他任何平台帮助公司更容易得使用微服务架构。

接下来,我们看一下微服务架构主要会面临哪些特性和挑战。

 

为什么要使用微服务?

在UX、安全性和集成性等各种需求不断变化的大环境下,微服务的首要任务就是,保证我们正在开发的系统在需求变化的同时还能够轻应对。

因为在现实环境中,软件必须不断接受改变才能更具竞争力,同时还要聚焦于去适应各种业务场景。

 

■发布

基于微服务架构,我们并不需要发布所有的项目。只需要对涉及到的几个服务,根据它们的发布周期进行版本管理即可。

尤其是当你有好几个团队使用各种不同工具,一起参与同一个庞大的项目时,这是一个非常大的优势。

 

■效率

您可以去扩展、优化或者变更一个小的业务场景,而不用把所有的模块放在一起进行评估。

但这时,我们需要团队之间具有高度的凝聚力,因为这种低耦合意味着需要高度的凝聚力。而为了加强这种团队之间的凝聚力,我们需要做大量的额外工作,这样反而有可能会导致我们丧失一定的效率。

 

■组织扩展性

组织的扩展性是使用微服务架构的一个主要优势。只有具备低耦合的团队,低耦合的技术,以及低耦合的业务场景,我们才能够让不同的团队,不同的技术和不同的业务场景在同一时间共同推进。

但在带来这些优势的同时,微服务架构也会给我们团队带来很多的挑战。

 

微服务带来的挑战

在使用微服务的同时,也会带来以下一些挑战:

■服务组合

正确定义微服务之间的边界是非常具有挑战性的。我们需要明白每个微服务必须且只能聚焦在一个业务场景上。

我们必须设计正确的服务边界,以避免相依性地狱(dependency hell)问题的爆发。现在很多已经使用微服务架构的公司仍然面临着这些问题。

 

■服务必须有自己的存储

而由此会带来一些挑战和架构决策:

数据共享(DATA SHARING)

通常我们会为每个需要进行数据交互的微服务定义API来进行数据共享。我们需要创建一系列的Web服务来进行CRUD操作和数据查询。

数据复制(DATA REPLICATION)

有时候使用API会非常缓慢,必须通过数据复制来加速查询。

事件溯源(EVENT SOURCING)

应用程序将事件保存到事件数据库中。事件数据库可以通过API来添加和检索实体事件。在这种方式下,通过事件溯源,微服务之间的沟通在很多情况下是异步的。

原子性和一致性(ATOMICITY AND CONSISTENCY)

因为现在存在好几个存储(有一个用于微服务),所以原子操作成了一个新的问题,由此又有了新的模式来解决这个问题。

 

■开发(DEVELOPMENT)

团队要处理大量的服务,而且这些服务要经常性地被重新发布。所以每个微服务都需要有一个发布计划和监控的系统。

 

GeneXus和微服务

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpppxy.html