Microservices创造了大量小型分布式用途单一的服务,每个服务拥有自己的数据。这种服务和数据耦合支持有界上下文和无共享体系结构的概念。h服务及其相应的数据区分开来,完全独立于所有其他服务。当您从单一应用程序迁移到微服务体系结构时,会发生数据驱动的迁移Anti-pattern。因为在创建微服务时,服务功能和相应的数据在开始时一起迁移。
任何微服务转换工作都有两个主要目标。第一种方法是将单一应用程序的功能拆分为小型、单一用途的服务。第二种方法是将单个数据迁移到每个服务拥有的小型数据库中。
开发微服务的重要方面是服务间通信。有两种通信风格,即同步与异步、一对一与一对多机制。
通信可以通过HTTP协议(如Thrift)和gRPC(取决于适用性)进行。当服务以同步方式通信时,将HTTP用于服务间通信是微服务的最佳选择。如果重试机制和稳定性很重要,那么Kafka或RabbitMQ之类的消息队列是理想的选
依赖关系管理是系统和软件设计的重要组成部分。当依赖关系周期涉及访问和修改服务的机制时,它是危险的。它还可以中断两个同时中断的恢复。如果两个系统都不可用,则无法重新启动演化为彼此依赖的两个系统。作业调度系统可能依赖于对数据存储系统的写入,但是数据存储系统可能依赖于作业调度系统向其分配资源。
源代码控制系统宕机导致源代码存储库和文档服务器不可用。获取源代码控制系统的文档或源代码的唯一方法是恢复相同的系统。如果没有关于系统内部的信息,工程师的响应就会受到严重阻碍。
像AWS Lambda和谷歌云函数这样的Serverless平台对于微服务来说是非常好的选择。它具有很高的可伸缩性,并降低了基础设施维护和部署的复杂性。代码必须遵循特定于平台的指导原则。因此,在开发微服务之前考虑后果是很重要的。
Kubernetes是另一个重要的可伸缩性工具。它是一个开源编排平台,用于跨主机集群自动部署、扩展和操作应用程序容器。这大大降低了维护和扩展微服务的复杂性。
微服务监视是其设计中涉及的一个非常重要的方面。确定每个日志是否与请求及其对应的服务相关联非常重要。我们应该在所有日志中都有一个惟一标识请求的链接ID。性能测试应该是开发过程的一部分。
在进行任何架构决策时,必须清楚地标识chmarks。
版本控制策略导致难以管理代码和依赖关系。应该为微服务体系结构制定有效的版本控制策略。最简单的策略之一是拥有一个API版本,并在路由URL中包含该版本。
微服务的设计依赖于组织的数据库。数据访问模式应该在微服务之间清楚地分开。有时候,通过多个服务实例使用一个数据库是很好的,只要数据是在明显独立的集合中。
共享库功能没有任何直接的业务价值,不需要单独作为一个微服务。日志、DB访问和服务通信等公共代码功能与业务目标没有直接关系,可以使用公共共享库。稍后,所有微服务都可以访问它。
许多公司正在寻找微服务体系结构风格,以利用性能测试、服务间通信、细粒度可伸缩性和总体敏捷性的优点。然而,在Techcello框架的帮助下,开发微服务的公司可以解决服务粒度、数据迁移、组织更改和分布式处理等挑战的解决方案