微服务架构开发电商系统需要用Redis、ES和MQ吗？

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

如果不用什么很高大上的东西，就是有多个微服务就行这种技术架构会很难吗？

我看了一些视频，他们都用到了es、mq、redis的东西，我想不用这些东西，就简单的有多个服务，这样可行吗？

01 使用微服务你考虑好了吗？

首先商场的开发要根据你的实际需要来定夺架构，例如，只是在微信小程序中商品滚动图片展示、产品分类、微信支付、订单、地址、简要配送信息，并且有一套后台管理系统，包括：用户、角色、商品、定价、订单等，基本上一个完整的商场系统就可以运行了。那么是不是要一定上微服务呢，还是单体服务就够用了呢？

需要上微服务架构最主要的目的就是为了解决服务功能频繁更新发布，导致总是影响业务大面积抖动，从而降低了新功能的敏捷迭代。因为对于单体服务，这个问题是无法避免的，一定会影响可靠性。

1. 分布式CAP： 但是我接触过的微服务项目，往往微服务发布机制都不成熟，实际上每次发布微服务和发布单体是一个效果，所有服务都得停下来重新部署。为什么呢？因为在线事务系统一定是优先考虑强一致性，无论什么开发团队遇到微服务，嘴上说得再漂亮，到了部署的时候，身体都会很诚实。微服务在分布式环境下对CAP理论的付诸实施，你是否已经了然于心了呢？

只要是联机事务，在微服务环境下依然要保证分布式强一致性。如下图所示：

2. 分布式事务： 微服务另外遇到的一个问题就是将单体应用对数据库的SQL操作拆分成了PRC远程协作，那么这个时候就可能涉及分布式事务。

如下图所示：发起端向支付微服务发起一次支付提交，完成支付后，支付微服务需要用RPC调用来通知订单服务更新订单状态，那么这时候系统就已经掉入到了分布式事务的漩涡。你是否为分布式事务做好准备了?

02 技术是随着业务规模的发展而逐步引入

其次，这些都对你来说都没有问题了，为什么还会有Redis，elasticsearch(es)，MQ呢? 那我们就一一分析一遍这些技术在商场中的作用，你自己去评估是否引入。

1. Redis： 主要作用是查询缓存，防止数据库被击穿，主要情境是商场出现了高并发的访问状态，不过也恭喜你，能用Redis证明你的业务很成功。

如下图所示：一个比较标准的MySQL读写分离，Redis作为查询缓冲区的联机事务处理的分布式架构耦。这种情况也是出现在MySQL读写分离都无法解决高并发带来的某个峰值时刻，对数据库的击穿，就需要通过增加一个二级缓存来解决。

请一定要注意，贯彻K.I.S.S原则，技术上能不加就不加的原则。因为总是要面对分布式的一致性问题，在加入Redis缓存这个问题，实际上这是目前工程师们非常流行的一种做法，但是在保证MySQL主从复制的一致性方面本身就存在不可控的复杂度，更何况，又引入缓存系统（Redis）和数据库（MySQL）之间的数据同步的一致性问题，会使得整体架构的复杂性更高，会导致上线后遇到很多不可预知的麻烦，所以在没有做好充分准备工作之前，增加架构复杂度的事情要慎之又慎。

2. Elasticsearch： 对于大量的商品内容检索，高级一点就不仅仅是分类关键字查询了，更需要是专业搜索提供的商品内容的全文内容检索，方便用户通过组合关键字，更快查找到自己想要的商品，除非你对自己的编程功底认为不错，可以直接用luence，否则es是个很不错的选择。

如下图所示：为架构纳入Elasticsearch专业搜索引擎，需要引入的技术操作流程，MySQL binlog->Canal->Kafka->Elasticsearch，这是一个binlog实时推送架构，效果最好，也最复杂。这就是表面说起来简单，但真要做好，内部都要沁透工程师的辛勤与汗水。

3. MQ： 当商场的微服务之间，以及商场与第三方服务之间形成犬牙交错的状况，一般微服务架构会形成事件驱动机制也就是EDA，例如订单发起后通过消息推送给下游，下游可能就是订单的配送系统接受处理。那么用到mq了，系统已经不再是一个小范围的商业服务了，应该算是平台级的！如下图所示：

当然mq的引入也不一定是发展到了规模化，也有可能一开始就面临O2O的业务需要，早期就需要将线上业务事件推送给线下业务系统，这就需要mq了，建议考虑支持分布式事务的mq，例如：rocketmq。如下图所示：传统企业搞互联网+，一开始就要考虑通过消息中心来解决线上线下的数据对接、信息安全、异步协作等问题。