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

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

如果不用什么很高大上的东西，就是有多个微服务就行这种技术架构会很难吗？我看了一些视频，他们都用到了es、mq、redis的东西，我想不用这些东西，就简单的有多个服务，这样可行吗？

什么是微服务

微服务Microservices之父，马丁.福勒，对微服务大概的概述如下：

就目前而言，对于微服务业界并没有一个统一的、标准的定义（While there is no precise definition of this architectural style ) 。 但通在其常而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。 另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务，也可以使用不同的数据存储。

小服务

小服务，没有特定的标准或者规范，但他在总体规范上一定是小的。

进程独立

每一组服务都是独立运行的，可能我这个服务运行在tomcat容器，而另一个服务运行在jetty上。可以通过进程方式，不断的横向扩展整个服务。

通信

过去的协议都是很重的，就像ESB，就像SOAP，轻通信，着意味着相比过去更智能更轻量的服务相互调用，就所谓smart endpoints and dumb pipes，这些endpoint都是解耦的，完成一个业务通信调用串起这些micro service就像是linux系统中通过管道串起一系列命令业务。

过去的业务，我们通常会考虑各种各样的依赖关系，考虑系统耦合带来的问题。微服务，可以让开发者更专注于业务的逻辑开发。

部署

不止业务要独立，部署也要独立。不过这也意味着，传统的开发流程会出现一定程度的改变，开发的适合也要有一定的运维指责

管理

传统的企业级SOA服务往往很大，不易于管理，耦合性高，团队开发成本比较大。微服务，可以让团队各思其政的选择技术实现，不同的service可以根据各自的需要选择不同的技术栈来实现其业务逻辑。

微服务的利与弊

为什么用微服务呢？因为好玩？

不是的。下面是我从网络上找到说的比较全的优点：

优点每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求开发简单、开发效率提高，一个服务可能就是专一的只干一件事。微服务能够被小团队单独开发，这个小团队是 2 到 5 人的开发人员组成。微服务是松藕合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。微服务能使用不同的语言开发。易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins,Hudson,bamboo。微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需- - 通过合作才能体现价值。微服务允许你利用融合最新技术。微服务只是业务逻辑的代码，不会和 HTML,CSS或其他界面组件混合。每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

总的来说，微服务的优势，就是在于，面对大的系统，可以有效的减少复杂程度，使服务架构的逻辑更清晰明了。

但是这样也会带来很多问题，就譬如分布式环境下的数据一致性，测试的复杂性，运维的复杂性。

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

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

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

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

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

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

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

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

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

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

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

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

总结

最后做个总结，对于上面聊的这些内容，我相信你心里至少应该有个底，可以明确一点——系统架构的技术体系都是不断迭代加厚，都是根据业务的需要不断地加持，逐步产生良好的业务支撑作用。

初期往往过度设计得越多，系统死掉的几率越大，因此微服务是不是一开始就要纳入设计? 系统性能优化，高级查询，复杂系统优化等等这些操作，是否需要在前期设计中完成?，是否已经有了与之匹配的团队组织形式? 这些都需要逐一斟酌，虽需长远规划但仍要从简入深。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。