title: “SecKill Develop Journey (III)” lang: en ref: seckill-development-journey-part-III permalink: /docs/seckill-development-journey-part-III/ excerpt: “an introduction how build seckill demo project step by step” last_modified_at: 2017-09-13T09:00:00+08:00 author: Yangyong Zheng tags: [seckill] redirect_from:
[Previous article]({{ site.url }}{{ site.baseurl }}/docs/seckill-development-journey-part-II/) we had built a full-featured seckill demo, release it version 0.1.0-RELEASE; now you should find that data persistence is centered on a single database, seckill is high-stress scenario, it's difficult to meet high-scalable requirement, and as we mentioned at the beginning, micro-service is recommended to have independent storage, so we will start using Event Sourcing implement CQRS pattern to enhance the ability to endure huge requests.
CQRS means Command Query Responsibility Segregation, it's a powerful design pattern, often implement with Event Sourcing, there has a figure describe it from Microsoft MSDN:
{: .align-center}
CQRS is read write separation and message-driven best practices, now we focus on the MySQL database:
Now the latest Architecture below:
{: .align-center}
Admin micro-service maintain Promotion entity;
Command micro-service write PromotionEvent Value-Object,when recovery Promotion,Relapy PromotionEvent.
Event micro-service write ActivePromotion Value-Object and Coupon Value-Object;
Query micro-service query ActivePromotion Value-Object and Coupon Value-Object.
Since the Event Sourcing was not introduced before, the PromotionEvent entity only needed to write to the database directly. Now it is necessary to publish PromotionEvent to Message Broker. Considering that future we will be replaced by Distributed Message Service (DMS) as Message Broker in order to deploy to Huawei Cloud, We defined the generic message publish interface:
public interface SecKillMessagePublisher { void publishMessage(String messageContent); }
Event micro-service subscribe Message Broker in order to get PromotionEvent Message, then depending on the message type convert to ActivePromotion Value-Object operation or Coupon Value-Object operation in ReadDB.
Promotion Start Message: create ActivePromotion Value-Object;
Promotion Finish Message: delete ActivePromotion Value-Object var Id;
Coupon Grabbed Message: create Coupon Value-Object;
Also considering that future we will be replaced by Distributed Message Service (DMS) as Message Broker in order to deploy to Huawei Cloud, We defined the generic message subscribe interface:
public interface SecKillMessageSubscriber { void subscribeMessage(String messageContent); }
After the refactoring of the read and write separation, all activing Promotion are saved in ActivePromotion Value-Object Table, and customers own Coupon are stored in Coupon Value-Object Table, now we can directly query them, no longer need Replay PromotionEvent.
Now, we have complete Event Sourcing architecture refactoring, in order to be easy to start-up, we provide docker compose script, use it pull all services up by one command, see detail at SecKill.
{: .align-center}