微服务学习笔记（一）微服架构初识

单体式架构

应用程序是一个总体，修改一部份内容，就整个从新打包部署。

抛问题：当用户流量大，一个服务器撑不住、搞不定的时候，怎么办？

​

你说我对服务器扩容？

不合适。举个栗子：一个电商网站，分为商品模块、用户模块、订单模块等，用户频繁访问的是商品模块，当流量大顶不住的时候，也是商品模块顶不住。若是你对服务器扩容，那么不怎么须要扩容的用户模块和订单模块也会跟着一块儿扩（项目耦合性强），对硬件资源是一种消耗。

怎么办？

把模块拆分，变为一个个子系统，好比商品系统、用户系统、订单系统，当流量大顶不住的时候，只拓展商品系统 。

微服务架构

讲白了就是原来有一个项目，在拓展的过程当中发现整个项目耦合性很是强，若是直接拓展，就会把其余的项目一块儿拓展了，为了不这种状况，咱们能够把这个项目拆分为一个个服务，当系统出现瓶颈的时候，咱们来分析一下，究竟是哪一个服务出现了瓶颈，而后对这个瓶颈进行一个相应的拓展，这就是微服务架构的概念了。

微服架构设计原则

• 围绕业务

  不解释

• 单一职责

  一个服务就作一件事情。虽然“订单”和“支付”看起来是一个模块里的，可是在微服务中是两个服务。“支付”分为支付宝支付啊微信支付啊等等，“订单”的话还须要增删改查订单，因此不是一回事儿，不坐一块儿讨论。

• 谁建立，谁负责

  单体式架构的时候，开发人员能够直接把包丢给运维，由运维负责部署啊维护啊，但由于微服务中各类配置、各个服务之间的关系只有开发人员最了解，因此它的维护工做也只能交给开发人员来作。

如何拆分一个业务？

举个栗子，需求以下：

模拟双十一商品抢购流程：

一、N个商品M个用户同时抢购某商品（M > N）

二、抢购成功的用户进行支付（支付宝、微信支付）

三、用户超时未支付，回退订单。

四、用户支付成功，减库存，修改订单信息、状态。

哇喔，有点乱，画个图先：

单体式架构中，这个业务被分为了四个模块。微服务架构中，首先分红四个项目，分别部署。

而后呢？

举个栗子：若是用户要下单，系统得先判断他是否登陆，因此确定须要调用用户项目获得用户数据，而后去调用商品项目信息，拿到用户挑选的商品信息，在本身的项目里面生成订单，再交给支付项目处理。

也就是说这四个项目互相之间须要通讯，并且每一个项目至少有两部分功能：一个是对外我要提供什么接口，你来访问我给你什么数据（项目提供者），一个是对内我须要对数据作什么样的处理加工（项目消费者）。

因此当前的业务需求一次性就可以衍生八个项目，随之你须要思考几个问题：

一、服务之间如何调用？（Dubbox...）

二、多个服务即有多个项目，如何快速部署？（Docker...）

三、多个服务之间如何实现事务？（MQ...）