微服务架构(1)——微服务架构介绍

目录：

1、单体应用的缺点
2、微服务的出现
3、微服务带来的问题和解决方案

单体应用的缺点

在之前我们开发一个应用，就是在我们本地把功能实现好，然后把整个应用打成一个war包，部署到一个web容器里面，这样在浏览器里面就能够访问我们的项目了。这样的一个应用我们称之为单体应用。这种应用开发简单，所有的功能都在本地，没有调用消耗。但是随着业务的发展，应用功能不断增加，几年之后这个应用变的又大又复杂。这个时候这种应用的缺点就凸显出来了。
单体应用架构如下：

缺点：
1、效率低：可能这个项目由10几个开发在维护，所有人都在同一个项目改代码。开发完了要合并到测试分支进行测试的时候，要一个个去合并，并且合并过程中需要解决各种冲突。对于任何一个小的改动可能都需要进行一次全量的测试回归。
2、维护难：因为这个项目太复杂，导致任何一个开发者都不可能搞懂它。因此，修改bug和添加新功能变的非常困难，并且很耗时。
3、不灵活：任何小修改都要重新编译整个项目。大部分时间可能都浪费在了编译和重启项目上了。
4、稳定性差：一个模块的bug，例如内存泄漏，可能导致整个应用都无法提供服务。
5、扩展难：当项目需要扩容的时候，不能对单个模块进行扩容，只能对整个项目进行扩容。比如说浏览商品的用户比较多，商品模块压力比较大，那这个时候只能增加一台机器，然后把整个项目部署上去。可是其它的模块压力并不是很大，根本就不需要进行扩容。

微服务的出现

为了应对上面这些问题，微服务就出现了。微服务就是把一个庞大的项目拆分为一个个小的服务，每个服务之间相互独立，可以单独进行部署和运行。
拆分为微服务后架构如下：

微服务带来的好处：
1、开发效率高：每个服务都是独立进行开发、测试、上线。使得每个服务的开发效率提高。
2、复杂性低：通过对一个项目进行拆分，解决了项目复杂性的问题。使得单个服务容易开发和维护。
3、灵活性高：每个服务都可以有专门开发团队来开发维护。对自己的服务做的修改不影响其他的团队的服务，开发者也可以自由选择开发技术，只需要保证对外提供的接口可以正常访问即可。
4、扩展性强：因为每个服务单独部署，所以可以针对压力大的服务进行单独扩容。

微服务带来的问题和解决方案

微服务在给我们带来方便的同时也带来其它的问题。
1、服务与服务之间会进行远程调用，地址如何维护，以及如何进行调用。
2、现在拆分成了多个服务，如何进行管理、监控和部署。
3、每个服务都是使用不同的数据库，分布式事务如何解决。
4、当一个服务故障的时候，如何保证其他功能能正常使用。
5、由于服务之间会相互调用，系统的故障如何能快速定位到具体的服务。
6、每个服务单独部署在不同的服务器上，日志如何进行集中管理等等一系列问题。

针对这么多问题，要是有一套完整的技术架构来去解决这些问题就非常完美了。那么有没有这样一套架构呢？

在早些年国内的一些大厂都是自研一些技术组件，像阿里开源的dubbo就是用来解决服务之间远程调用的问题。

在之前阿里对dubbo维护的比较活跃的时候，国内的一些中小型公司大部分是以阿里开源的dubbo+zookeeper+其它的一些开源组件来作为微服务的技术架构。

后来阿里对dubbo的维护不是那么活跃了，再加上国外netflix公司把他的微服务技术组件进行了开源，并且Spring将这些开源组件进行整合，组成了一个比较完善的微服务技术架构（spring cloud）对外推出。于是在后面一段时间国内中小型公司更偏向于使用spring cloud。

然后在最近几年Netflix公司开源的微服务组件开始更新的不活跃了，而且Netflix也公开宣布在未来不会再更新之前开源的这些组件。这时阿里dubbo也重新变得活跃起来，同时也把微服务技术栈融入进了spring cloud体系和标准 ，组成了一个spring cloud alibaba微服务技术架构。然后国内使用spring cloud alibaba的公司又变的越来越多了。

spring cloud 与 spring cloud alibaba对比图：