微服务概述 ¶

微服务基础 1课时 ¶

01 | 到底什么是微服务？-极客时间
图解微服务技术架构体系_51CTO博客_微服务架构技术
什么是微服务架构 - 微服务架构核心20讲
(2 封私信) 什么是DevOps？ - 知乎 (zhihu.com)

• 什么是微服务
  • 维基百科是如何定义微服务的。微服务的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出，他们定义了微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通讯。同时，服务会使用最小规模的集中管理 （例如 Docker）技术，服务可以用不同的编程语言与数据库等。
• 单体应用
  • 早期，各大互联网公司技术栈
    • 早些年，各大互联网公司的应用技术栈大致可分为 LAMP（Linux + Apache + MySQL + PHP）和 MVC（Spring + iBatis/Hibernate + Tomcat）两大流派。无论是 LAMP 还是 MVC，都是为单体应用架构设计的，其优点是学习成本低，开发上手快，测试、部署、运维也比较方便，甚至一个人就可以完成一个网站的开发与部署。
    • 以 MVC 架构为例，业务通常是通过部署一个 WAR 包到 Tomcat 中，然后启动 Tomcat，监听某个端口即可对外提供服务。早期在业务规模不大、开发团队人员规模较小的时候，采用单体应用架构，团队的开发和运维成本都可控。
  • 业务规模扩大后，面临的问题
    • 部署效率低下：当单体应用代码和依赖资源增多时，应用编译打包、部署测试一次需要10分钟以上，影响开发效率。
    • 团队协作开发成本高：团队人员扩张后，超过5人修改代码一起打包部署，测试阶段出现问题需要重新编译打包部署，开发成本高。
    • 系统高可用性差：所有功能开发部署到同一个WAR包中，运行在同一个Tomcat进程中，某一功能出现问题会影响整个WAR包中的服务。
    • 线上发布变慢：Java应用代码膨胀，服务启动时间变长，机器规模超过100台以上，单次发布需要100分钟以上，急需降低开发和部署成本。
  • 想要解决上面这些问题，服务化的思想也就应运而生。
• 服务化与微服务化
  • 服务化
    • 通俗的话讲：服务化就是把传统的单机应用中通过 JAR 包依赖产生的本地方法调用，改造成通过 RPC 接口产生的远程方法调用。一般在编写业务代码时，对于一些通用的业务逻辑，我会尽力把它抽象并独立成为专门的模块，因为这对于代码复用和业务理解都大有裨益。
    • 插一张图。
    • 以微博系统为例，微博既包含了内容模块，也包含了消息模块和用户模块等。其中消息模块依赖内容模块，消息模块和内容模块又都依赖用户模块。当这三个模块的代码耦合在一起，应用启动时，需要同时去加载每个模块的代码并连接对应的资源。一旦任何模块的代码出现 bug，或者依赖的资源出现问题，整个单体应用都会受到影响。
    • 为此，首先可以把用户模块从单体应用中拆分出来，独立成一个服务部署，以 RPC 接口的形式对外提供服务。微博和消息模块调用用户接口，就从进程内的调用变成远程 RPC 调用。这样，用户模块就可以独立开发、测试、上线和运维，可以交由专门的团队来做，与主模块不耦合。进一步的可以再把消息模块也拆分出来作为独立的模块，交由专门的团队来开发和维护。
    • 可见通过服务化，可以解决单体应用膨胀、团队开发耦合度高、协作效率低下的问题。
  • 微服务化相比于服务化的4个特点
    • 服务拆分粒度更细。微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都没有关系，那么就可以拆分为一个微服务。
    • 服务独立部署。每个微服务都严格遵循独立打包部署的准则，互不影响。比如一台物理机上可以部署多个 Docker 实例，每个 Docker 实例可以部署一个微服务的代码。
    • 服务独立维护。每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维，并对整个生命周期负责。
    • 服务治理能力要求高。因为拆分为微服务之后，服务的数量变多，因此需要有统一的服务治理平台，来对各个服务进行管理。
    • 继续以前面举的微博系统为例，可以进一步对内容模块的功能进行拆分，比如内容模块又包含了 feed 模块、评论模块和个人页模块。通过微服务化，将这三个模块变成三个独立的服务，每个服务依赖各自的资源，并独立部署在不同的服务池中，可以由不同的开发人员进行维护。当评论服务需求变更时，只需要修改评论业务相关的代码，并独立上线发布；而 feed 服务和个人页服务不需要变更，也不会受到发布可能带来的变更影响。
    • 由此可见，微服务化给服务的发布和部署，以及服务的保障带来了诸多好处。
• DevOps与CICD DevOps漫谈之一：DevOps、CI、CD都是什么鬼？ - 晶晶的博客
  • DevOps
    • 维基百科定义：DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
  • CICD
    • Continuous Integration，Continuous Deployment。是实现DevOps的必然要求，是一种Pipeline。
    • 持续集成（CI）是在源代码变更后自动检测、拉取、构建和（在大多数情况下）进行单元测试的过程。
    • 持续部署（CD）是将代码版本变更持续地部署到指定环境，包括开发集成环境、测试环境、生产环境等。
  • DevOps是一种思想和文化；CICD是一套工具。
• 微服务的优缺点及总结 微服务架构的优缺点 • Worktile社区
  • 优缺点：
    • 优点
      • 灵活性高：将应用程序分解成松耦合的小型服务，使其开发、维护更便捷，也更容易理解。
      • 独立扩展：复杂系统中的不同功能模块，被拆分成多个微服务后，每个微服务独立运行在自己的进程内，有足够的扩展性。
      • 支持多语言：团队根据自己的技术栈，想用java，go，python都可以。
      • 自动部署与持续集成：Jenkins等工具，天然地支持微服务的自动部署和持续集成。
      • 通用性：根据不同的业务需求，可选地部署不同的微服务组件。如阿里的业务中台战略。
        • 
    • 缺点
      • 处理故障难度高：分布式系统，需要有互相通信的机制来处理故障
      • 部署工作量大：每个服务有不同的实例，每个实例都需要配置、部署、伸缩、监控。
      • 测试复杂度高：某种角度而言，增加了集成测试的复杂度。
      • 部署和运营成本增加：一套系统，以前是一次安装搞定，现在可能要部署安装几十个微服务。
      • 发布风险高：若管理不善，一个特性可能伴随着多个微服务的适配，集成点的大量增加，会有更高的发布风险。
      • 分布式系统通常问题：分布式系统的网络延迟、容错性、异步机制等等问题
  • 总结：
    • 将复杂的单体应用进行细粒度的服务化拆分，每个拆分出的服务各自进行独立打包部署，并交由小团队进行开发和运维，从而极大地提高了应用持续交付的效率。
      • 单体应用、服务化、DevOps与CICD

微服务核心模式及原理 2课时 ¶

特征

• 一组小的服务
• 独立的进程
• 轻量级通信
• 基于业务能力
• 独立部署
• 无集中式管理

2. 微服务架构设计

• 微服务拆分策略
• 微服务组件设计
• 微服务通信方式
• 微服务部署模式

微服务研发概述 2 ¶

3. 微服务开发实践

• 微服务开发流程
• 微服务开发框架
• 微服务测试策略
• 微服务持续集成与部署

4. 微服务监控与运维

• 微服务监控指标
• 微服务日志管理
• 微服务故障处理
• 微服务的可伸缩性与负载均衡

5. 微服务安全与治理

• 微服务安全架构
• 微服务认证与授权
• 微服务数据保护
• 微服务治理与管理

微服务化案例解析 2 ¶