微服务解读

1、什么是微服务

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

1.1、单体服务

前些年，我们开发用的技术几乎都是MVC结构（如果不知道什么是MVC，那先去别的地方看看），这种项目开发完成，打成一个war包，就可以直接部署到服务器了。部署完成后，通过http协议可以访问了。开发过程中，如果有别的第三方的功能要依赖，要么对方提供给我们一个jar包，要么通过web services服务访问，传输过程中，使用xml技术。这就是单体服务！可以这么简单理解：开发完成后打成一个包的项目，一般都是单体服务。
单体服务存在的问题：

• 部署效率低下：当代码比较多，依赖的资源也比较多时，打包、部署一次需要10分钟左右，我们之前部署在ws上，添加一次war包，基本等待就是10分钟。
• 团队协作成本太高：两三个人协同开发还好，当人数在10人左右时，很容易出问题。忘记提交代码等小问题，都要再来一次重新打包部署。而且，10个模块中，有任何一个有问题，就得重新打包部署。
• 线上发布慢：当要部署集群的时候，上面的问题极为突出。
• 高可用性差：由于所有的代码都在一个包里，并允许在一个tomcat中，一旦有一个功能出问题，特别是性能问题，将影响整个系统。我曾经碰到的项目，有几个功能往页面上返数据时，由于没有数据的忽略，每次几乎将库中关联的数据全盘拉出，系统出现超时或404，其他功能几乎访问不了。

2、服务化

简单来说，服务化就是把单机系统中通过jar包依赖的调用，重构成通过RPC接口方式的远程方法调用。当然，不是把所有的方法都改造，是抽取项目中的公共模块。比如任何系统中都有用户模块，可以把用户模块抽取处理，单独部署，要访问用户是，调用用户模块提供的接口就行了。

3、微服务

这几年，由于有了Docker技术，服务化演变成微服务。微服务和服务化的差别，有以下几点：

• 服务独立部署：每个微服务独立部署，互不影响
• 服务独立维护：每个微服务都可以交给一个小团队开发维护
• 服务拆分粒度更细：微服务可以说是更细的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都没有关系，那就可以拆分成一个微服务。
• 治理要求高：由于拆分，产生了多个服务，服务数量变多，那就需要有相关的服务治理工具，来管理这些服务。

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