微服务是架构演进的结果，要理解什么是微服务需要找出它之前出现的架构，找出他们之间的不同点。
单体架构
即所有功能模块的代码都放在一个项目中，打包成一个应用程序，统一部署和运行。因此，这种架构的特点也是显而易见的，就是方便管理。
当业务模式单一，团队规模较小时，单体架构简单且高效。但是当业务开始变得复杂时，产品规模越来越大时，这种架构的缺点就开始显现了：
- 项目庞大导致无法维护。由于所有功能模块都在一个项目中，团队成员很难分而治之，维护起来必然困难重重；
- 资源共享导致无法隔离。单体架构中，各模块往往共享数据库和内存等资源。当其中一个模块对资源的使用过载时，会影响其他模块对资源的使用，使整个系统受影响；
- 统一打包导致无法灵活扩展。系统中每个功能模块的访问量各不相同，当某个功能模块的访问量上升时，为了保证这个模块的正常使用，不得不对整个系统进行水平水平扩展，消耗过多的资源。
微服务架构
微服务架构要求应用程序按照业务功能进行构建小型的应用程序，每个应用程序在自己的进程中运行，并独立打包和部署。应用程序之间使用轻量级的机制进行通讯，比如Http接口。这样每个应用程序就可以根据业务特点，使用不同的技术和资源。相对于单体应用的三个缺点，微服务有以下优势：
- 独立部署，灵活扩展。以每个独立组件（例如用户服务，商品服务）作为一个微服务单独部署；
- 资源隔离。每个微服务使用独立的资源。如果A微服务要使用B微服务的资源，则需要通过B微服务暴露出来的接口才可以使用。这样避免了资源竞争带来的问题；
- 项目可以分而治之。由于每个微服务已经按照业务功能进行划分，因此研发团队能够据此拆分成更小的团队，更专注于某各业务。同时，产品规模的拆分也带动了代码规模的拆分，这种更有力于代码维护。
与SOA架构的区别
SOA又有一个名字，叫做服务治理。为了把各个子系统之间乱七八糟的调用关系给治理起来，需要提供一个统一的标准，各个系统分别根据统一标准向数据总线进行注册，各子系统调用其他子系统时，不用关心如何找到其他子系统，只需要找到数据总线，数据总线会根据统一标准找其他子系统。所以它解决的是异构系统之间的服务通信，解除各子系统直接的耦合。
由此可以知道，SOA架构强调的是异构系统之间的通信和解耦合，而微服务架构强调的是系统按业务边界做细粒度的拆分和部署。
与框架和组件的区别
微服务是一种思想，该架构的设计目标是为了肢解业务，使得服务能够独立运行。而我们平时使用的Dubbo和SpringCloud都是实现微服务架构的框架。这些框架能为我们在搭建微服务架构遇到问题时，提供有效的解决方案，比如：
- 分布式/版本化配置
- 服务注册和发现
- 路由
- 服务之间的调用
- 负载均衡
- 断路器
- 全局锁
- leader选举和集群状态
- 分布式报文传送
若有收获，就点个赞吧
0 人点赞
