这篇文章的知识点包括：微服务的概念、微服务的优缺点、微服务的架构以及微服务的使用示例，阅读完整文相信大家对会有一定的认识。
以购物车应用程序为例，当打开购物车应用程序时，您看到的只是一个网站。但是，在后台，购物车应用程序具有用于接受付款服务，客户服务等
假设此应用程序的开发人员使用了单体框架，架构如下图
如图，在单体架构中，所有功能都放在一个代码库中，并在一个基础数据库下
现在，假设市场上出现了一个新品牌，并且开发人员希望将即将到来的品牌的所有详细信息放入此应用程序中
此时，不仅需要处理新品牌的服务，而且还必须重新构建整个系统并相应地进行部署。为了避免此类挑战，开发人员决定将其应用程序从单体架构转换为微服务
以旅游行业应用程序为例
虽然现在程序被分成了三层，但只是逻辑上的分层，并不是物理上的分层。也就是说，对不同层的代码而言，经过编译、打包和部署后，所有的代码最终还是运行在同一个进程中
单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多，主要有以下几点：
单块架构中，整个系统运行在同一个进程中，当应用进行部署时，必须停掉当前正在运行的应用，部署完成后再重启进程，无法做到独立部署 有时候我们会将重复的代码抽取出来封装成组件,在单块架构中,组件通常的形态叫做共享库(如jar包或者DLL),但是当程序运行时,所有组件最终也会被加载到同一进程中运行。
<李>
<李>
<李>
<李>
<李>
<李>
<李>
<李>
<李>
<李>
<李>
<李>
沟通与事件广播
微服务的规划与单体式应用程序十分不同,微服务中每个服务都需要避免与其他服务有所牵连,且都要能够自主,并在其他服务发生错误时不受干扰
倘若真有沟通,也应采用异步沟通的方式来避免紧密的相依性问题。要达到此目的,则可用下列两种方式:
事件存储中心(事件存储)
这可以让你在服务集群中广播事件,并且在每个服务中监听这些事件并作处理,这令服务之间没有紧密的相依性,而这些发生的事件都会被保存在事件存储中心里。这意味着当微服务重新上的线,部署时可以重播(重播)所有的事件。这也造就了微服务的数据库随时都可以被删除,摧毁,且不需要从其他服务中获取数据
