什么是微服务？

参考文章：java|什么是微服务

1.单体应用：

        传统的单体应用都是MVC架构的javaweb项目，所有的模块都是集成在一个JVM进程中

 优点：

        所有代码都在一个项目中，方便管理。

缺点：

        这个项目包含的四个模块都是相互依赖的，当这些模块的代码耦合到一起时，需要去加载每个模块的代码以及连接资源，任何一个出了问题，整个应用都会受到影响。

1、项目过于臃肿，部署效率低下

        当大大小小的功能模块都集中在同一项目的时候，整个项目必然会变得臃肿，让开发者难以维护。单体应用的代码越来越多，依赖的资源越来越多时，应用编译打包、部署测试一次非常耗时。

2、系统高可用性差，资源无法隔离
        整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮。

3、开发成本高

早期在团队开发人员只有两三个人的时候，协作修改代码，打包部署，更新发布这完全可以控制。但是团队一旦扩张，还是按照早期的方法去开发，那如果测试阶段只要有一块功能有问题，就得重新编译打包部署。所有的开发人员又都得参与其中，效率低下，开发成本极高。
 

2.什么是服务化？

        用通俗的语言来说，服务化就是把传统单体应用中通过 JAR 包依赖产生的本地方法调用，改造成 RPC 接口产生的远程方法调用。这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。

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

3.什么是微服务

        简而言之，微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。

微服务有什么样的具体特点呢？

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

2、服务独立部署
        传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（例如用户服务，商品服务）为单位进行部署。

用一张经典的图来表现，就是下面这个样子：

 

        什么意思呢？比如根据每个服务的吞吐量不同，支付服务需要部署100台机器，用户服务需要部署30台机器，而商品服务只需要部署10台机器。这种灵活部署只有微服务架构才能实现。

3、服务独立维护，分工明确
        每个微服务都可以交由一个小团队进行开发，测试维护部署，并对整个生命周期负责。比如在单体应用时期，我们的研发团队是如下图这样传统的水平架构：

        而微服务时期，我们可以根据其思想把团队划分成垂直组织架构： 

 

        当然，这种垂直划分只是一个理想的架构，实际在企业中并不会把团队组织架构拆分得这么绝对。