简述 “微服务”（什么是微服务）

内容： 记录微服务的概念

wiki对微服务的定义：

微服务的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出，他们
定义了微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务
功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通讯。同时，服务会使用最小
规模的集中管理 （例如 Docker）技术，服务可以用不同的编程语言与数据库等。

单体应用：

早期在业务规模不大、开发团队人员规模较小的时候，采用单体应用架构，团队的开发和运维成本
都可控。然而随着业务规模的不断扩大，团队开发人员的不断扩张，单体应用架构就会开始出现问题。


1、部署效率低下
当单体应用的代码越来越多，依赖的资源越来越多时，应用编译打包、部署测试一次，需要的时间
越来越长长。部署测试一次的时间，都可以去楼下喝杯咖啡了。

2、团队协作开发成本高
早期在团队开发人员只有几个人的时候，协作修改代码，最后合并到同一个 master 分支，然后
打包部署，尚且可控。但是一旦团队人员扩张，多人修改代码，然后一起打包部署，测试阶段只要、
有一块功能有问题，就得重新编译打包部署，然后重新预览测试，所有相关的开发人员又都得参与
其中，效率低下，开发成本极高。

3、系统高可用性差
所有的功能开发最后都部署到同一个包里，运行在同一个进程之中，一旦某一功能涉及的代码或者
资源有问题，那就会影响整个包中部署的功能。比如：某段代码不断在内存中创建大对象，并且
没有回收，部署到线上运行一段时间后，就会造成 JVM 内存泄露，异常退出，那么部署在同一个
 JVM 进程中的所有服务都不可用，后果十分严重。

4、线上发布变慢
特别是对于 Java 应用来说，一旦代码膨胀，服务启动的时间就会变长，有些甚至超过10分钟
以上，如果机器规模超过 100 台以上，假设每次发布的步长为 10%，单次发布需要就需要100
分钟之久。因此，急需一种方法能够将应用的不同模块的解耦，降低开发和部署成本。

服务化：

服务化就是把传统的单机应用中通过 JAR 包依赖产生的本地方法调用，改造成通过 RPC 接口
产生的远程方法调用。一般在编写业务代码时，对于一些通用的业务逻辑，我会尽力把它抽象并
独立成为专门的模块，因为这对于代码复用和业务理解都大有裨益。

以微博系统为例，微博既包含了内容模块，也包含了消息模块和用户模块等。其中消息模块依赖
内容模块，消息模块和内容模块又都依赖用户模块。当这三个模块的代码耦合在一起，应用启动时，
需要同时去加载每个模块的代码并连接对应的资源。一旦任何模块的代码出现 bug，或者依赖的
资源出现问题，整个单体应用都会受到影响。

为此，首先可以把用户模块从单体应用中拆分出来，独立成一个服务部署，以 RPC 接口的形式对
外提供服务。微博和消息模块调用用户接口，就从进程内的调用变成远程 RPC 调用。这样，用户
模块就可以独立开发、测试、上线和运维，可以交由专门的团队来做，与主模块不耦合。进一步的
可以再把消息模块也拆分出来作为独立的模块，交由专门的团队来开发和维护。

可见通过服务化，可以解决单体应用膨胀、团队开发耦合度高、协作效率低下的问题。

微服务：

从 2014 年开始，得益于以 Docker 为代表的容器化技术的成熟以及 DevOps 文化的
兴起，服务化的思想进一步演化，演变为今天我们所熟知的微服务。

那么微服务相比于服务化又有什么不同呢？

1、服务拆分粒度更细
微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都
没有关系，那么就可以拆分为一个微服务。

2、服务独立部署
每个微服务都严格遵循独立打包部署的准则，互不影响。比如一台物理机上可以部署多个 Docker
实例，每个 Docker 实例可以部署一个微服务的代码。
 
3、服务独立维护
每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维，并对整个生命周期负责。

4、服务治理能力要求高
因为拆分为微服务之后，服务的数量变多，因此需要有统一的服务治理平台，来对各个服务进行管理。

总结：

微服务架构是将复杂臃肿的单体应用进行细粒度的服务化拆分，每个拆分出来的服务各自独立打包
部署，并交由小团队进行开发和运维，从而极大地提高了应用交付的效率，并被各大互联网公司所
普遍采用。

大四学生一枚，如果文章有错误的地方，欢迎在下方提出，每条评论我都会去认真看并回复，同时感谢指正的前辈。有喜欢C/C++，linux的同学欢迎私信一起讨论学习。

本文地址：https://blog.csdn.net/qq_43684922/article/details/107524884