什么是微服务架构

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

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

微服务的本质

特点

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

优点

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

缺点

• 增加分布式系统的复杂度
• 增加运维成本
• 需要部署自动化
• 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）部分变成一个非常简洁、轻量级的应用，更关注如何渲染页面以及表单提交等交互功能，做到真正的前后端分离。

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

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