开发者学堂课程【全面讲解 Spring Cloud Alibaba 技术栈：系统架构演变-下】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/683/detail/11855
系统架构演变-下
内容介绍
一、微服务架构（服务的原子化拆分）
二、微服务架构优缺点
三、选择与使用
一．微服务架构（服务的原子化拆分）
本次课程主讲微服务架构。什么叫微服务架构：这个名词最重点是“微”，他提倡的是服务的原子化拆分。
在垂直应用架构里，已经开始对各个模块儿进行拆分了。那么微服务架构，它强调的是原子化拆分，也就是往小了拆，拆到最小为止。比如说对于一个电商来讲，可能会拆成如下图：
商品微服务是处理跟商品相关的信息，其他的一概不管；用户微服务是处理用户信息；秒杀微服务是只处理秒杀业务；当然还可以再有各种各样的微服务，将这个微服务拆到最小为止。
而外边类似椭圆的圈，就表示一个 web 中间件。我们将每一个微服务都执行单独部署，就相当于是圈中产生了一系列的小的应用系统。作为用户来讲，他想用哪个功能就去调用哪一个微服务就可以了。
之后就有了这样一张关系图：
以下为简化关系图：
注意：大矩形只是一个逻辑上的圈，用户是可以访问进来的，这就是我们的微服务的概念。
二．微服务架构优缺点
微服务架构在某种程度上是面向服务架构 SOA 的进一步的发展，它强调的是微服务的“彻底拆分”。那么它的优点和缺点分别是什么？
优点：
- 服务进行了原子化拆分以后，就可以对每一个微服务进行独立的打包部署和升级，不会影响到其他的微服务，保证每个微服务的任务划分，利于扩展。
而且每个微服务都遵循单一职能原则，他只管自己的事情，比如说用户就管用户的，商品就管商品的，他们之间现在是没有交流的。他们有着清晰的任务划分，利于扩展。比如说现在秒杀任务来了，下订单处于一个飙高并发的状态，我们可能需要两个订单微服务才能支撑住，这时候我们把订单微服务这个小的原子，再搞出一份来就可以了，那么其他的微服务不会受到影响。
还有一个优点，我们用户维护，商品维护，都是单独存在的，那么在企业中必然会有一些联系。怎么联系？我们要下订单，下订单之前需要查询商品的信息才能下订单，那么下完订单得发物流。其实这里面都是要有联系的，怎么联系呢？
- 微服务之间，我们采用的是 Restful 风格等轻量级 http 协议相互调用
这个词现在听不懂也没关系，后面我们还会提及，只用知道它是通过一些非常轻量级的协议进行调用的就可以了。
缺点：
- 分布式系统开发的的技术成本高（容错、分布式事务等）
如图所示：
这里面可能要进行一些链路的追踪，服务的监控，服务的配置治理，以及消息总线，各种各样的技术都会在这里面出现，对于一些小型系统来讲，用它反而会麻烦。
三、选择与使用
这五个服务架构没有哪一个最好之说。架构各自有各自的优缺点，如果要做一个非常非常小的项目，就是想玩儿一玩儿，这时候单体用架构可能是一个最好的选择。如果说要做一个非常大的项目，可能有成千上百个服务在里面，那可能微服务架构是一个是更好的选择。所以说，在企业开发中用哪个架构完全取决于你项目的大小特征，没有说哪一个服务架构会更好，好的多少，这就是微服务架构的简单介绍。下节课会针对微服务里边的一些问题作进一步的讲解。
