从零开始学微服务学习笔记（一）

微服务，从放弃到入门

什么是微服务

微服务体系

• 微服务发展到现在，已经不再单单局限于微服务架构本身，还与容器化、DevOps 等新的理念相结合，成为当前移动互联网时代最先进的业务架构解决方案，能更好地迎合移动互联网业务快速迭代的要求。
• 微服务架构的基本原理
  • 什么是微服务？
  • 什么时候适合微服务改造？
  • 微服务架构到底是什么样的？
• 掌握微服务架构改造过程中可能会遇到的问题和对应的解决方案，以及搭建微服务架构时，如何做技术选型。
• 理解微服务、容器化、DevOps 这三者之间的关系以及在具体实践中如何运用这三种技术给业务的架构带来质的飞跃，并且了解下一代微服务体系可能的发展方向。

单体应用

• 早些年，各大互联网公司的应用技术栈大致可分为 LAMP（Linux + Apache + MySQL +
  PHP）和 MVC（Spring + iBatis/Hibernate + Tomcat）两大流派。
  • 无论是 LAMP 还是 MVC，都是为单体应用架构设计的，其优点是学习成本低，开发上手快，测试、部署、运维也比较方便，甚至一个人就可以完成一个网站的开发与部署。
  • 以 MVC 架构为例，业务通常是通过部署一个 WAR 包到 Tomcat 中，然后启动 Tomcat，监听某个端口即可对外提供服务。
  • 早期在业务规模不大、开发团队人员规模较小的时候，采用单体应用架构，团队的开发和运维成本都可控。
• 随着业务规模不断扩大，团队开发人员不断扩张，单体应用架构就会开始出现问题。
  • 部署效率低下
    • 当单体应用的代码越来越多，依赖的资源越来越多时，应用编译打包、部署测试一次，甚至需要 10 分钟以上。
  • 团队协作开发成本高
    • 早期在团队开发人员只有两三个人的时候，协作修改代码，最后合并到同一个 master 分支，然后打包部署，尚且可控。
    • 但是一旦团队人员扩张，超过 5 人修改代码，然后一起打包部署，测试阶段只要有一块功能有问题，就得重新编译打包部署，然后重新预览测试，所有相关的开发人员又都得参与其中，效率低下，开发成本极高。
  • 系统高可用性差
    • 因为所有的功能开发最后都部署到同一个 WAR 包里，运行在同一个 Tomcat 进程之中，一旦某一功能涉及的代码或者资源有问题，那就会影响整个 WAR 包中部署的功能。
  • 线上发布变慢
    • 特别是对于 Java 应用来说，一旦代码膨胀，服务启动的时间就会变长，有些甚至超过 10 分钟以上。
    • 因此，急需一种方法能够将应用的不同模块的解耦，降低开发和部署成本。

什么是服务化

• 服务化就是把传统的单机应用中通过 JAR 包依赖产生的本地方法调用，改造成通过 RPC 接口产生的远程方法调用。
• 一般在编写业务代码时，对于一些通用的业务逻辑，尽量把它抽象并独立成为专门的模块，这对于代码复用和业务理解都大有裨益。
• 以微博系统为例，微博既包含了内容模块，也包含了消息模块和用户模块等。
  • 其中消息模块依赖内容模块，消息模块和内容模块又都依赖用户模块。
  • 当这三个模块的代码耦合在一起，应用启动时，需要同时去加载每个模块的代码并连接对应的资源。
  • 一旦任何模块的代码出现 bug，或者依赖的资源出现问题，整个单体应用都会受到影响。
  • 为此，首先可以把用户模块从单体应用中拆分出来，独立成一个服务部署，以 RPC 接口的形式对外提供服务。
  • 微博和消息模块调用用户接口，就从进程内的调用变成远程 RPC 调用。
  • 这样，用户模块就可以独立开发、测试、上线和运维，可以交由专门的团队来做，与主模块不耦合。
  • 进一步的可以再把消息模块也拆分出来作为独立的模块，交由专门的团队来开发和维护。
  • 可见通过服务化，可以解决单体应用膨胀、团队开发耦合度高、协作效率低下的问题。

什么是微服务

• 微服务相比于服务化有什么不同：
  • 服务拆分粒度更细。
    • 微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都没有关系，那么就可以拆分为一个微服务。
  • 服务独立部署。
    • 每个微服务都严格遵循独立打包部署的准则，互不影响。
  • 服务独立维护。
    • 每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维，并对整个生命周期负责。
  • 服务治理能力要求高。
    • 因为拆分为微服务之后，服务的数量变多，因此需要有统一的服务治理平台，来对各个服务进行管理。
• 继续以微博系统为例，可以进一步对内容模块的功能进行拆分，比如内容模块又包含了 feed 模块、评论模块和个人页模块。
  • 通过微服务化，将这三个模块变成三个独立的服务，每个服务依赖各自的资源，并独立部署在不同的服务池中，可以由不同的开发人员进行维护。
  • 当评论服务需求变更时，只需要修改评论业务相关的代码，并独立上线发布。
  • feed 服务和个人页服务不需要变更，也不会受到发布可能带来的变更影响。
  • 由此可见，微服务化给服务的发布和部署，以及服务的保障带来了诸多好处。