Skip to main content

Microservices Patterns

2022/7/31

摘自Microservices Patterns

Monolithic hell​

image-20220731103629296

单app囊括了所有功能，在早期开发很便捷，breaking changes也很容易做。

image-20220731104010734

不同team contribute到同一个repo，可想而知这里面的conflict resolving issue有多少。

image-20220731104221551

同时，Chris还主张每个service都有自己的data schema和data store，这样就不会出现修改entity影响其他服务的情况。

Benefits​

小，容易维护。各个team自治，为引入新技术提供便捷。

互相独立，错误隔离。

Drawbacks​

很难找到最合适的服务设计（Find the right set of services）

测试协调比较困难

有些Feature需要多个team合作，协调（e.g. rollout plans）

同时，如果要从monolithic向microservice 转变，时间点很难选择

Three sections​

Forces - issues must be addressed

Resulting context

  • Benefits: forces resolved
  • Drawbacks: forces unresolved
  • Issues: new problems introduced

Related patterns

  • Predecessor
  • Successor
  • Alternative
  • Generalization
  • Specialization

image-20220731105805840

image-20220731105939843

image-20220731110052915

Communication Overhead​

the communication overhead of a team of size N is O(N^2^)

4+1 View​

image-20220731110515932

Defining an application’s microservice architecture​

从Functional requirement开始

Single Responsibility Principle​

A class should have only one reason to change. Robert C. Martin

Obstacles​

Maintaining data across services

Network latency

Synchronous communication

IPC​

HTTP based REST or gRPC

Dimensions​

1 to 1 or 1 to many

(A)Synchronous

Rest drawbacks​

It only supports the request/response style of communication.

Reduced availability. Because the client and service communicate directly without an intermediary to buffer messages, they must both be running for the duration of the exchange.

Clients must know the locations (URLs) of the service instances(s). As described in section 3.2.4, this is a nontrivial problem in a modern application. Clients must use what is known as a service discovery mechanism to locate service instances.

Message broker​

image-20220731125022170

这个结构的Drawback就在于单点故障和Performance bottleneck。很幸运，有了cloud，这两个问题都可以很好地解决。

但是，由于还是存在理论上故障的可能，很多message queue都保证deliver message at least once.

因此要保证所谓的idempotent，幂等，也就是多次相同消息的作用和一次是一样的。

API的调用通常是同步的，而消息驱动则是异步的。

ACID (Atomicity, Consistency, Isolation, Durability)

Saga​

image-20220731132244740

保证事务的原子性，要在事务fail之后做compensate roll back steps

Domain Driven Design​

DDD, each domain model being owned and developed by a single team

image-20220731160443551

Aggregates​

数据的整合是避不开的。理想情况下，整合应该尽可能小。

Idempotent messages​

RDBMS-BASED, message ID可以很好地辨别是否是重复的message