0 初识微服务

Wed, Nov 7, 2018

 

0x0 微服务导学

微服务：就是普通的项目模块，运行在Docker里面，使用K8S管理Docker们

为什么要做微服务？

• 系统越来越复杂
• 不同模块之间技术栈差异很大，管理复杂

0x1 认识微服务

软件架构的进化

软件架构：在软件内部，经过综合各种因素的考量、权衡，选择特定的技术，将系统划分成不同的部分并使这些部分相互分工，彼此协作，为用户提供需要的价值。

• 考虑的因素
  • 业务需求（首位）
  • 已有技术栈
  • 成本
  • 组织架构（多少个小组，每个小组能做什么）
  • 可扩展性
  • 可维护性（系统的学习成本、新人上手成本、Bug修复成本）
• Java web的架构演进
  • 一层架构
    • 老系统：JSP - 页面、业务逻辑、数据库都放在一起
  • MVC
    • 三层架构，纠结M到底是啥 - 其实很多概念就是用来迷惑我们的让我们纠结
    • 解决了代码调用杂乱无章的问题。通过在各层之间定义接口，让接口和维护分离，降低了维护成本
  • dubbo
    • 背景：业务代码50w+行，产品需求不断，新人一个月上不了手，需要做拆分 - 一个大项拆成两个小项
    • 系统前端和后端服务可以从物理上管理开，变成两个可以单独维护的模块
    • 把一个单体架构变成了两个单体架构

单体架构：

• 三层架构只是对逻辑的拆分，物理上并没有拆分出来。最终还是运行在同一台机器的同一个进程里
• 对于把功能、业务集中在同一个发布包里，部署运行在同一个进程中的应用，叫单体架构
  • 这么看来，客户端开发天生的就是「单体架构」...如果放宽一些要求，不考虑部署在几台机器上的话，「分包加载」「热更新」可能是客户端演进的方向...
• 优势：

1. 1. 易于开发
   2. 易于测试（启动一个服务，所有功能就都准备好了）
   3. 易于部署
   4. 易于水平伸缩（新建一个服务器，配好环境，复制软件包就好）

• 挑战
  1. 维护成本的增加，代码膨胀难以维护（引入新Bug）
  2. 持续交付周期长（构建、部署成本大）- 一次完整的Bug修复到提交给测试的周期拉的非常长
  3. 新人上手困难
  4. 创新困难（统一的前后端技术，完成所有功能），很难对现有的技术栈做扩展
  5. 可扩展性差（垂直扩展、水平扩展不容易，机器贵）

什么是微服务

微服务：

1. 定义：使用一套小服务来开发单个应用的方式。
   1. 每个服务运行在独立的进程里
   2. 一般采用轻量级的通讯机制互联
   3. 可以通过自动化的方式部署
2. 理解
   1. 微：如何判断
      1. 代码量？不靠谱
      2. 开发时间？更不靠谱
      3. 结论：不可度量
         1. 传递的是设计思想，而不是「量」
   2. 特征：
      1. 单一职责：只把紧密相关的业务放在一起，无关业务独立出去 - 登录和注册、订单和支付、邮件服务、短信服务
      2. 轻量级通信：平台、语言无关的通信 - http
      3. 隔离性：运行在自己的进程中，不相互干扰
      4. 有自己的独立数据存储系统
      5. 技术的多样性：开发人员选择最适合的技术实现业务需求，只要能提供出适合的API就好了
3. 诞生背景
   1. 互联网行业的快速发展：需求变化快、用户数变化快
   2. 敏捷开发、精益方法的深入人心：最小的代价做最快的迭代，看到反馈 - 频繁的修改测试上线
   3. 容器技术的成熟 - Docker的出现解决运维瓶颈

画一个微服务架构图

业务场景

在线教育网站的部分功能

• 登录注册
• 发邮件发短信
• 查看课程及课程的CRUD

单体架构图

说明：

• 虚线框：物理机器
• 大实线框：一个应用

微服务拆分

问题：

• 一个业务场景可能同时调用上百个微服务，这样客户端代码会非常复杂
• 不是每个微服务都能提供RESTful API的，只能适用内部访问
• 难以重构
  • 客户端1.0上线了，如果我们想拆接口或者合并接口，为了兼容客户端很难修改

解决方式：API Gateway

• 一种服务，进入系统的唯一节点
• 封装系统架构，提供唯一的接口给客户端
• 可以有其他功能：授权、监控、负载均衡、缓存

微服务架构的优势和不足

优势

独立性：每个服务只需要管理好自己就好

• 每个服务的数据访问体量可能不同，如：登录注册（QPS 10）、用户信息（QPS 100）
  • 可以启动2个登录注册服务，5个用户信息服务
• 容错：出现问题只会影响它自己，可以快速恢复
• 独立的数据库，让数据表的多少、结构变得简单，最多只能影响到它自己

敏捷性：

• 接口简单，使用者容易理解、应对变化

技术栈灵活：

• 可以有自己独立的技术栈

高效团队：

• 团队规模小，每个团队只负责自己的微服务

不足

额外的工作：

• 服务的拆分（如何把服务拆解成微服务 - 服务拆分相关知识可以了解下DDD领域驱动设计）
  • 拆分的太小，会造成服务之间调用过多
  • 拆分的太大，会失去微服务的优势
• 数据一致性
  • 单体架构只有一个数据库，使用事务，保证数据的一致性
  • 微服务多个数据库
    1. 拆分的时候尽量避免产生「连表操作」
    2. 很难避免数据一致性问题的挑战
• 沟通成本
  • 微服务的API改变带来的沟通成本
  • 单体架构：改了API可以顺手改了调用的地方
  • 微服务：需要推动其他组做修改