背景:现在微服务大行其道,虽然微服务开山鼻祖是不建议在微服务下做分布式事务,领域驱动设计早已阐明,具有强一致性要求的一组业务概念,属于同一个聚合,不建议拆到不同服务中,从而尽可能避免分布式强事务一致性的处理。但是不可避免我们没有真的按照DDD领域驱动设计,那么微服务如何保持事务一致性呢?
我们这里采用的EventStore的方式,有基于memory、jpa、jdbc等方式,我今天采用了MapDB framework的方式,MapDB提供多种多样方式的数据结构有link、set、map、queue等。
EventMessage
public interface Message<T> extends Serializable {
String getIdentifier();
MetaData getMetaData();
T getPayload();
Class<T> getPayloadType();
Message<T> withMetaData(Map<String, ?> metaData);
Message<T> andMetaData(Map<String, ?> metaData);
}
MapDB eventStore
/**
* Created by Young on 2017/4/11.
*/
public class MapDBEventStorageEngine implements EventStorageEngine {
private final DB db = DBMaker.memoryDB().make();
private static final String ORDER_LINK_LIST = "ORDER_LINK_LIST";
private final Lock lock = new ReentrantLock();
private final Condition dataAvailableCondition = lock.newCondition();
@Override
public void appendEvents(List<? extends EventMessage<?>> events) {
lock.lock();
try {
IndexTreeList<Object> hs = db.indexTreeList(ORDER_LINK_LIST).createOrOpen();
hs.addAll(events);
} finally {
lock.unlock();
}
}
@Override
public void storeSnapshot(DomainEventMessage<?> snapshot) {
}
@Override
public Stream<? extends TrackedEventMessage<?>> readEvents(TrackingToken trackingToken, boolean mayBlock) {
return null;
}
@Override
public DomainEventStream readEvents(String aggregateIdentifier, long firstSequenceNumber) {
return null;
}
@Override
public Optional<DomainEventMessage<?>> readSnapshot(String aggregateIdentifier) {
return null;
}
}