微服务

微服务是最近两年流行起来的一种架构设计方法,可以很好的和Docker,Kubernetes结合起来.

从最早的"单体应用"到"SOA(面向服务的架构)“再到"微服务架构”,这些新东西都是大公司搞出来的最佳实践.

软件界的真理是没有银弹,所以如果要上微服务,你就得在部署,测试和监控等其他地方做的更好(自动化),否则系统的复杂度伴随分布式系统反而上升了,得不偿失.

不得不说ThoughtWorks搞敏捷,微服务这些新概念真的很六,但是中小公司得沉住气,晚点上车

下面记录之前的一些整理.

什么是微服务

这里必须提到大神Martin Flower早在2014年的这篇文章.大致为:

• 服务组件化
  • 组件: 可以独立更换和升级的单元
  • 服务件HTTP通讯
• 按业务组织团队
  • 全栈的要求
• 做产品的态度(而非项目)
  • 持续关注并提升
• 智能终端和哑管道: 粗粒度通讯(非RPC)
  • HTTP Rest
  • 轻量级消息
  • 强调性能用二进制
• 去中心化治理
  • 技术选型独立
• 去中心话数据管理/存储
  • 每个服务管理自己的数据库
  • 数据一致性保证
    • 服务件’无事务’调用
    • 保证最终一致性
• 基础设施(运维)自动化
  • 持续交付
    • 自动化测试
    • 自动化部署
• 容错设计
  • 快速检测故障并自动恢复
    • 监控和日志
      • 服务状态,断路由状态,吞吐量,延迟
• 演进式设计
  • 单体monolith 到 (部分)微服务

微服务网络

Service Mesh

十二要素应用宣言

这个宣言是Heroku发布的构建SaaS(软件即服务)应用的方法论。虽然和微服务不直接相关,也适合作为参考。

• 使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入项目；
• 和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性；
• 适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源；
• 将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发；
• 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展；

这套理论适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序。

• 基准代码:一份基准代码,多份部署
• 依赖:显式声明依赖关系
• 配置: 推荐将应用的配置存储于环境变量
• 后端服务: 将后端服务当作附加资源
• 构建,发布,运行: 严格区分三个步骤
• 进程:以一个或多个无状态进程运行应用
• 端口绑定
• 并发
• 易处理: 快速启动和优雅终止可最大化健壮性
• 开发环境和线上环境等价
• 日志
• 管理进程

概念

• 循证架构:架构基于实践的证据、来自历史项目或亲自试验的经验(适合应用需求的架构), By Rod Johnson.
• ESB: 企业服务总线, SOA的组成部分.
• OSGi: Open Service Gateway Initiative, Java模块化技术,慎用.

资源

• <微服务设计> by Sam Newman
• <微服务：从设计到部署>在线阅读
• Chris Richardson 微服务系列
• 十二要素
• 设计一个容错的微服务架构