向微服务迈进，目的->前提->边界->治理


目录

  • 目的：微服务的驱动力
  • 前提：微服务需要的条件
  • 边界：微服务的粒度
  • 治理：理解系统复杂性
  • 静态的治理
  • 发展的治理


软件研发中任何一项技术、方法、架构都不可能是银弹。

假如只能用一个词来形容微服务解决问题的核心思想，笔者给的答案就是“分治”，这即是微服务的基本特征，也是微服务应对复杂性的手段。

目的：微服务的驱动力

硬件的成本能够持续稳定地下降，而软件开发的成本则不可能。微服务最主要的目的是对系统进行有效的拆分，实现物理层面的隔离，微服务的核心价值就是拆分之后的系统能够让局部的单个服务有可能实现敏捷地卸载、部署、开发、升级，局部的持续更迭。

外部因素：

  • 当意识到没有什么技术能够包打天下：java、python、golang不同的语言擅长做不同的事情
  • 当个人能力因素成为系统发展的明显制约：在单体架构下，系统中“整体”与“部分”的关系没有物理的划分，难以阻止大量螺丝钉式的程序员或外包人员在不起眼的地方犯错并产生全局的影响
  • 当遇到来自外部商业层面对内部技术层面提出的要求：甲方招投标文件技术规范明文要求

内部因素：

  • 变化发展特别快的创新业务系统往往会自主地向微服务架构靠近：需求、开发、运维肯定都是很乐意接受微服务
  • 大规模的、业务复杂的、历史包袱沉重的系统也可能主动向微服务架构靠近

前提：微服务需要的条件

  • 决策者与执行者都能意识到康威定律在软件设计中的关键作用，沟通决定设计，技术层面和组织层面不一致，会造成沟通成本上升或管理成本上升
  • 组织中具备一些的对微服务有充分理解、有一定实践经验的技术专家，微服务架构对普通开发者友善，对架构者满满的恶意
  • 系统应具有以自治为目标的自动化与监控度量能力，三个前提：环境预置，基础监控，快速部署
  • 复杂性已经成为制约生产力的主要矛盾，接受演进式架构

边界：微服务的粒度

“识别微服务的边界”其实已取得了较为一致的观点，也找到了指导具体实践的方法论，即领域驱动设计（Domain-Driven Design，DDD）。

但系统设计是一种创作，而不是应试，不可能每一位架构师设计的服务粒度全都相同，微服务的大小、边界不应该只有唯一正确的答案或绝对的标准，但是应该有个合理的范围，笔者称其为微服务粒度的上下界（下界：表示微服务粒度太小，上界：表示微服务粒度太大）。

微服务粒度的下界是它至少应满足

  • 独立：能够独立发布、独立部署、独立运行与独立测试
  • 内聚：强相关的功能与数据在同一个服务中处理
  • 完备：一个服务包含至少一项业务实体与对应的完整操作

微服务的上界并非受限于技术，而是受限于人，更准确地说，受限于人与人之间的社交协作

  • 微服务粒度的上界是一个 2 Pizza Team 能够在一个研发周期内完成的全部需求范围

治理：理解系统复杂性

治理就是让产品能够符合预期地稳定运行，并能够持续保持在一定的质量水平上。

静态的治理

复杂性的来源：

  • 复杂性来自认知负荷：分布式系统带来更高的认知负荷，面向资源，异步通讯，容错处理，去中心化等。
  • 复杂性来自协作成本：协作的沟通复杂度，沟通成本= n×(n-1)/2，n 为参与项目的人数

结论：软件规模小时微服务的复杂度高于单体系统，规模大时则相反。这里的原因就是微服务的认知负荷较高，但是协作成本较低。

假如只能用一个词来形容微服务解决问题的核心思想，笔者给的答案就是“分治”，这即是微服务的基本特征，也是微服务应对复杂性的手段。

发展的治理

架构腐化是软件动态发展中出现的问题，任何静态的治理方案都只能延缓，不能根治，必须在发展中才能寻找到彻底解决的办法。治理架构腐化唯一有效的办法是演进式的设计。