概览
“微服务”是一个非常广泛的话题，在过去几年里，市面上存在着各种不同的定义。
虽然对这种架构方式没有一个非常精确的定义，但仍然有一些概念具有代表性。
微服务有着许多围绕业务能力、自动化部署、终端智能化、分布式数据以及其他与团队相关的一些特性。
为了更好地说明，我们参考了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和微服务
我们认为微服务是一种很抽象的概念和技术。您可以使用任何语言或技术来构建微服务。但后续的维护和实施支撑可能会抵消掉这种系统架构设计带来的一切优势。
GeneXus的理念是创建、维护和演进前所未有的软件解决方案。我们一直致力于在许多方面演进GeneXus产品，以便通过GeneXus能够去创建未来的系统，尤其是使用微服务架构设计的系统。
我们相信使用GeneXus在面对这些挑战时，解决的唯一方式是通过基于知识库的设计，充分了解所有的服务内容，并且掌握维护和演进它们的方法。
为什么通过GeneXus来实现微服务是一个不错的选择？
⬛ 微服务所有的内容必须由一个小团队来完成
当您有一个非常完整的团队架构时，一些工作很有可能会被安排给好几个不同的团队来完成。例如，后端服务团队，安全团队，数据建模团队，前端开发人员等等。
而当您在一个微服务体系架构中开发时，您应该聚焦在业务场景。您的团队一般来说是一个小团队，但又必须能完成微服务所有层面的工作内容。
而这对于GeneXus开发人员是非常好的，因为GeneXus自一开始就是以这种方式工作的。
在开发微服务时，你必须考虑到服务的各个架构层都需要编程（用户界面层，数据层，业务层）。如果你是使用GeneXus的话，这些工作则会变得简单且更高效。
在这方面，我们在GeneXus 16中加入了更多的特性，能够让一个小团队使用微服务架构实现一个业务场景的完整功能。
我们加入了UX、集成和安全等方面的一些特性。就GeneXus的UX而言，一个小团队就可以使用人工智能创建智能终端，也可以为我们的业务场景开发移动APP，Web以及聊天机器人等多体验的终端应用。
⬛ GeneXus可以解决数据演变和共享所面临的挑战
数据共享、原子数据、事件溯源等这些问题都可以通过GeneXus来解决。
GeneXus为所有微服务的数据模型演变提供了最佳的解决方式。这些都可以在GeneXus知识库中通过我们的方法完美实现。
但是对于微服务架构，为了将多个服务隔离开，您可能会有多个知识库。
GeneXus 16整合了新的数据存储，这些数据存储能够完美匹配一些实现模式（如事件溯源）。我们已经集成了对Kafka、DynamoDB的支持，之后还将继续添加新的数据源，例如Hyperledger Blockchain，以及更多能够支持不同实现模式的数据源。
我们每两个月就会发布一个新的版本，很快我们即将发布的版本会实现用更高层级的抽象方式来处理以下几个微服务模式：
●事件溯源（EVENT SOURCING）
即使在现在的GeneXus版本中，您也可以通过使用例如Serverless和Kafka或DynamoDB或者其他的DBMS来实现此模式。我们正努力实现将事件建模抽象到更高一个层次的方法。
●API演变分析（API Evolution Analysis）
如今，微服务演变的主要关注点之一就是API的演变。对于GeneXus而言，这些工作和数据演变一样，都能够自动完成。
●封装（Encapsulation）
我们正致力于使用知识矩阵（Knowledge Matrix.）来增强模块（Module）的功能，以及模块共享的方式。通过其他几个特性之间的知识矩阵，团队会具备发现、共享和发布服务的能力。该矩阵将会有一个在线版本和企业内部安装版本。我们要时刻谨记，微服务的一个主要挑战就是避免相依性地狱（dependency hell）问题。所以我们将整合几个工具，以便更广泛得了解系统是什么。
●观察（Observable）
当有很多服务时能够使扩展性得到更大的效果，但每个服务都应该能通过日志或者相关的消息来观察。
在GeneXus 16中，我们集成了新的日志API，它可以与Elastic Stack（Logstach, Elastic Search 和Kibana）结合使用，以便收集和分析操作信息。
⬛ 使用BPM整合微服务
人工智能和工作流是任何行业打造未来系统中最重要的技术。人工智能是当今最热门的话题话题之一，为了能够在服务中使用，GeneXus已经集成了一个GeneXus AI模块。同时我们相信BPM是整合微服务最重要的工具，为此，GeneXus已经内置了一个工作流工具。
BPM仍然在不断的演进，以解决更复杂的模式，例如SAGAs服务。在微服务架构中，GeneXus有很强的业务流程建模、执行和监控方面的基础。
⬛ 通过GeneXus能够实现完全的自动化发布
团队和服务都应该使用自动化技术，这样才能保证管理和运维的高效。自动化是GeneXus的基础理念。
如果您不能引入各个开发方面的自动化，那么使用大量的微服务反而会变得一团糟。
-
GeneXus Server
将开发流程进行pipeline管理方式，最简单的开始方法是通过GeneXus和GXserver为项目建立分支/版本模型。
GXserver提供SCM和PipeLine控制（开发、构建、SCA、测试、原型和发布）的功能。
开发/构建 ---> Jenkins Plugin + MSBuild Tasks
SCA ---> KBDoctor and Security Scanner
测试---> GXtest V4
原型和发布--> Docker容器和发布到PaaS或Serverless
-
持续集成（CI）
CI意味着每当开发人员在GXserver的KB上进行了一些修改的时候，代码都会触发一些自动化操作，以检查最新的修改是否可以成功得构建一个新版本，而且不会与其他开发冲突。同时，还会检查是否有缺失的引用需要提交，以能够在与开发完全不同的环境中构建成功。
GeneXus发布了一个集成Jenkins的插件，需要注意，如果在GeneXus项目中要使用Jenkins，需要先安装该插件，该插件能够支持SCM和构建集成。
-
持续交付（CD）
CD是一种软件开发策略，以使公司能够尽可能快速、高效地给客户发布新功能。
随着持续交付概念的出项，也出现了pipeline概念。在软件中，pipeline表示一系列排列的处理节点，每个节点的输出都是下一个节点的输入。这意味着pipeline将软件的交付分解为几个阶段，每个阶段都要验证新功能的品质，以防止这些bug影响到用户。Pipeline的目的是如果检测到问题，则将在流程的每个节点反馈给开发团队。
为了实现Pipeline的目的，我们必须将每个阶段中能够自动化的事情全部自动化。每个阶段都必须能够自动运行测试、供应、发布、安装以及配置测试和阶段环境，这样才能保证开发人员能够收到反馈。每次向Pipeline中添加代码时，都必须定义验证方法。当代码通过各个阶段时，都会被测试并反馈它的状态信息。
-
Docker容器发布
能够让您构建GeneXus应用的Docker镜像，然后可以在端对端的CD Pipeline管理中的每个发布阶段使用它们。
-
GXtest 4.0
则通过采用为GeneXus开发人员、QE以及DevOps工程师设计的DevOps实践和敏捷方法，以促进GeneXus社区使用和提高开发流程
总结
GeneXus一直在努力整合新的功能和技术，以让团队在接下来的几年中，能够使用各种不同的架构设计，其中包括微服务架构。
成功地应用微服务架构需要基于一个良好的自动化策略，我们相信GeneXus对于任何想使用微服务的公司是一个最佳选择。微服务架构不仅仅是技术层面的选择，同时还是一种不同的工作方式。而GeneXus将一直在这方面努力！