什么是微服务架构

是一种架构模式，提倡将单一的应用程序划分成一组小的服务，服务之间相互协调、相互配合，为用户提供最终价值。

微服务架构其实是将单一的应用程序划分成一组小的服务，每个服务都是具有业务属性的独立单元，同时能够被独立开发、独立运行、独立测试以及独立部署。

微服务的本质

特点

  • 服务作为组建
  • 围绕业务组建团队
  • 关注产品而非项目
  • 技术多样性
  • 业务数据独立
  • 基础设施自动化
  • 演进式架构

优点

  • 独立性
  • 单一职责
  • 技术多样性
  • 进程隔离

缺点

  • 增加分布式系统的复杂度
  • 增加运维成本
  • 需要部署自动化
  • DevOps 文化与调整组织架构
  • 服务间依赖测试保证质量
  • 服务间强依赖管理

微服务架构与 SOA 的区别

SOA 实现 微服务架构实现
企业级，自顶向下开展实施 团队级，自底向下开展实施
服务由多个子系统组成，粒度大 一个系统被拆分成多个系统，粒度细
企业服务总线，集中式的服务架构 无集中式总线，松散的服务架构
集成方式复杂（ESB、WS、SOAP） 集成方式简单（HTTP、REST、JSON）
单块架构系统，相互依赖，部署复杂 服务能独立部署

注：SOA 是面向服务架构，对于复杂的企业 IT 系统，应按照不同的、可重用的颗粒度划分，将功能相关的一组功能提供者组织在一起为消费者提供服务。

微服务架构你需要做的事情

  • RESTful APi 通讯
  • 学习 Docker 构建技术
  • 持续交付
    • 搭建持续集成环境（Snap-CI、Travis-CI、Jenkins、Go、Spinnaker、CircleCI）
    • 代码编译、静态检查、运行单元测试
    • 运行集成测试、运行用户行为测试、运行组建测试、运行性能测试
  • 日志聚合（Splunk、LogStash ）
  • 监控（Nagios、NewRelic、OneAPM、Zabbix、Ganglia）与告警（PagerDuty）

服务间的通信机制对比

RPC REST HAL 消息队列 后台任务系统
通讯方式 同步通讯 同步或者异步通讯 同步或者异步通讯 异步通讯 异步通讯
平台依懒性 强 平台无关 平台无关 强 弱
语言支持 好 语言无关 语言无关 好 中
学习成本 高 低 低 高 低
维护成本 高 低 低 高 低

如何使用微服务架构重构项目

  • 最小修改：新功能进行评审，非紧急、非重要的任务都禁止在原有的系统进行修改，将工作重心从现有系统逐渐迁移到新的服务中。
  • 功能剥离：逐步构建功能服务接口，将系统核心功能分离出来，对原有的系统访问转发到新的服务中。
  • 数据解耦：逐渐从原有的单块架构数据库中剥离相关的业务数据。
  • 数据同步：将服务中的业务数据同步到单块架构的数据库中，保障原有的功能能够被继续使用。
  • 迭代替换：通过不断的迭代替换组件将功能结构成独立的服务，最终将原有的系统替换成使用微服务架构的新系统。

总结

由于微服务具有高内聚，低耦合的特点，每个应用都是一个独立的个体，当出现问题时，很容易定位问题并解决问题，大大缩短了修复缺陷的周期。

另外，通过使用不同功能的微服务结构提供数据，用户接口（UI）部分变成一个非常简洁、轻量级的应用，更关注如何渲染页面以及表单提交等交互功能，做到真正的前后端分离。

最后我还想说的是，微服务架构不是银弹，使用微服务架构是需要很大成本的，只有数据和业务达到一定的量级还能发挥好微服务架构的优势。

注：以上内容是《微服务架构与实践》的读书笔记。