How Anti-Patterns Can Constrain Microservices Adoption

Microservices创造了大量小型分布式用途单一的服务,每个服务拥有自己的数据。这种服务和数据耦合支持有界上下文和无共享体系结构的概念。h服务及其相应的数据区分开来，完全独立于所有其他服务。当您从单一应用程序迁移到微服务体系结构时，会发生数据驱动的迁移Anti-pattern。因为在创建微服务时，服务功能和相应的数据在开始时一起迁移。

任何微服务转换工作都有两个主要目标。第一种方法是将单一应用程序的功能拆分为小型、单一用途的服务。第二种方法是将单个数据迁移到每个服务拥有的小型数据库中。

微服务间通信

开发微服务的重要方面是服务间通信。有两种通信风格，即同步与异步、一对一与一对多机制。

通信可以通过HTTP协议(如Thrift)和gRPC(取决于适用性)进行。当服务以同步方式通信时，将HTTP用于服务间通信是微服务的最佳选择。如果重试机制和稳定性很重要，那么Kafka或RabbitMQ之类的消息队列是理想的选

跟踪和控制微服务依赖关系

依赖关系管理是系统和软件设计的重要组成部分。当依赖关系周期涉及访问和修改服务的机制时，它是危险的。它还可以中断两个同时中断的恢复。如果两个系统都不可用，则无法重新启动演化为彼此依赖的两个系统。作业调度系统可能依赖于对数据存储系统的写入，但是数据存储系统可能依赖于作业调度系统向其分配资源。

源代码控制系统宕机导致源代码存储库和文档服务器不可用。获取源代码控制系统的文档或源代码的唯一方法是恢复相同的系统。如果没有关于系统内部的信息，工程师的响应就会受到严重阻碍。

Serverless vs. Kubernetes

像AWS Lambda和谷歌云函数这样的Serverless平台对于微服务来说是非常好的选择。它具有很高的可伸缩性，并降低了基础设施维护和部署的复杂性。代码必须遵循特定于平台的指导原则。因此，在开发微服务之前考虑后果是很重要的。

Kubernetes是另一个重要的可伸缩性工具。它是一个开源编排平台，用于跨主机集群自动部署、扩展和操作应用程序容器。这大大降低了维护和扩展微服务的复杂性。

监控和性能测试

微服务监视是其设计中涉及的一个非常重要的方面。确定每个日志是否与请求及其对应的服务相关联非常重要。我们应该在所有日志中都有一个惟一标识请求的链接ID。性能测试应该是开发过程的一部分。

在进行任何架构决策时，必须清楚地标识chmarks。

控制版本控制策略

版本控制策略导致难以管理代码和依赖关系。应该为微服务体系结构制定有效的版本控制策略。最简单的策略之一是拥有一个API版本，并在路由URL中包含该版本。

微服务工作负载数据访问模式的设计

微服务的设计依赖于组织的数据库。数据访问模式应该在微服务之间清楚地分开。有时候，通过多个服务实例使用一个数据库是很好的，只要数据是在明显独立的集合中。

共享库

共享库功能没有任何直接的业务价值，不需要单独作为一个微服务。日志、DB访问和服务通信等公共代码功能与业务目标没有直接关系，可以使用公共共享库。稍后，所有微服务都可以访问它。

许多公司正在寻找微服务体系结构风格，以利用性能测试、服务间通信、细粒度可伸缩性和总体敏捷性的优点。然而，在Techcello框架的帮助下，开发微服务的公司可以解决服务粒度、数据迁移、组织更改和分布式处理等挑战的解决方案