单体式架构
应用程序是一个整体，修改一部分内容，就整个重新打包部署。
抛问题：当用户流量大，一个服务器撑不住、搞不定的时候，怎么办？
你说我对服务器扩容？
不合适。举个栗子：一个电商网站，分为商品模块、用户模块、订单模块等，用户频繁访问的是商品模块，当流量大顶不住的时候，也是商品模块顶不住。如果你对服务器扩容，那么不怎么需要扩容的用户模块和订单模块也会跟着一起扩（项目耦合性强），对硬件资源是一种消耗。
怎么办？
把模块拆分，变为一个个子系统，比如商品系统、用户系统、订单系统，当流量大顶不住的时候，只拓展商品系统。
微服务架构
讲白了就是原来有一个项目，在拓展的过程中发现整个项目耦合性非常强，如果直接拓展，就会把其他的项目一起拓展了，为了避免这种情况，我们可以把这个项目拆分为一个个服务，当系统出现瓶颈的时候，我们来分析一下，到底是哪个服务出现了瓶颈，然后对这个瓶颈进行一个相应的拓展，这就是微服务架构的概念了。
微服架构设计原则
围绕业务
不解释
单一职责
一个服务就做一件事情。虽然“订单”和“支付”看起来是一个模块里的，但是在微服务中是两个服务。“支付”分为支付宝支付啊微信支付啊等等，“订单”的话还需要增删改查订单，所以不是一回事儿，不坐一起讨论。
谁创建，谁负责
单体式架构的时候，开发人员可以直接把包丢给运维，由运维负责部署啊维护啊，但因为微服务中各种配置、各个服务之间的关系只有开发人员最了解，所以它的维护工作也只能交给开发人员来做。
如何拆分一个业务？
举个栗子，需求如下：
模拟双十一商品抢购流程：
1、N个商品M个用户同时抢购某商品（M > N）
2、抢购成功的用户进行支付（支付宝、微信支付）
3、用户超时未支付，回退订单。
4、用户支付成功，减库存，修改订单信息、状态。
哇喔，有点乱，画个图先：
单体式架构中，这个业务被分为了四个模块。微服务架构中，首先分成四个项目，分别部署。
然后呢？
举个栗子：如果用户要下单，系统得先判断他是否登录，所以肯定需要调用用户项目得到用户数据，然后去调用商品项目信息，拿到用户挑选的商品信息，在自己的项目里面生成订单，再交给支付项目处理。
也就是说这四个项目互相之间需要通信，而且每个项目至少有两部分功能：一个是对外我要提供什么接口，你来访问我给你什么数据（项目提供者），一个是对内我需要对数据做什么样的处理加工（项目消费者）。
所以当前的业务需求一次性就能够衍生八个项目，随之你需要思考几个问题：
1、服务之间如何调用？（Dubbox...）
2、多个服务即有多个项目，如何快速部署？（Docker...）
3、多个服务之间如何实现事务？（MQ...）