什么是微服务

2016-08-28 本文已影响5633人老瓦在霸都

多年以来, 开发者们受够了大而全的系统, 代码越积越多, 层次越做越深, 逻辑复杂, 结构混乱, 牵一发而动全身, 说好的高内聚, 松耦合几乎做不到.

相比大而全, 人们更喜欢小而美, 微服务 Microservice 就此应运而生.

微服务就是微小紧凑的服务, 提供统一简捷的 API 供外部访问, 实现一组独立的功能.

在讲微服务之前, 先让我们回顾一下服务 Service 和面向服务的架构 SOA

SOA 面对服务的架构

多年以前, SOA 面向服务的架构已经风靡一时了, 在这么多年的企业应用中也已达成共识. 我们所设计的应用架构应该是面向服务的. 在如何提供服务方面, 私有的协议显示不利于服务的广泛使用, 当时的 DCOM, RMI, CORBA又显得笨重, 不够轻盈. 于是 Web Service 大行其道.

W3C当时给出的定义是

服务 Service: 服务即一个软件系统, 它设计用来支持在机器之间的通过网络进行交互与协作
Web Service: Web 服务有一个以机器可处理的格式(WSDL)表示的界面, 其它系统以 SOAP 消息与此 Web 服务交互, 多通过 HTTP 协议加上 XML 消息格式以及其他 Web 相关的标准

时过境迁, W3C后来扩展上述定义, 将 Web Service 分为两大类

REST 兼容的 Web 服务, 其主要目的是使用一套统一的无状态操作来操作 web 资源的表示形式
随意的 Web 服务, 提供一些随意的操作集合

Web Service 和 SOA

SOA 所提出的理念和微服务是一脉相承的, 我们可以先简单回顾一下 SOA 宣言和原则

SOA 宣言

面向服务是一种规范行为的范式.
面向服务的架构是一种应用于面向服务而形成的架构类型
我们一直以来运用面向服务来帮助组织始终如一的交付可持续的业务价值, 以提高灵活性和成本效益, 与变化的业务需求保持一致

在我们的工作中, 我们会作如下优先级的考虑

业务价值高于技术策略
战略目标高于特定项目的利益
本质上的互操作性高于特殊定制的整合
共享的服务高于为特定目标所做的实现
灵活性高于优化
演进式的精进高于追求初始的完美

也就是说, 我们认为右边的要素有其价值,但我们更加重视左边要素的价值

SOA 指导原则

我们遵循如下原则

尊重组织的社会和权力结构
认可SOA最终要求在许多层面上的变化
采用SOA的范围可以多种多样, 确保工作量可控并处于有意义的范围内
产品和标准本身既不会给你 SOA ,也不会为你应用面向服务的范式
SOA 可以通过不同的技术和标准来实现
建立一套统一基于工业界, 实践和社区标准的企业标准和策略
追求外在的统一性的同时允许内在的多样性
通过与业务和技术的利益相关者协作来识别服务
通过考虑当前和未来的使用范围来最大化服务的使用率
验证服务满足于业务的需求和目标
根据实际使用情况来演化服务及其组织
以不同速率变化的系统的不同方面予以分离
减少隐含的依赖并公布所有外部依赖, 以增强系统的健壮性, 减少依赖变化造成的影响
在每一层的抽象, 围绕一个紧密结合和易于管理的功能单元来组织每个service

SOA 大获成功, 经久不衰, 可也遭到了不少问题, 在服务的组织方面, 人们希望能够快速地应对变化, 单个服务不必太大, 功能最好相对独立和完整, 各自提供不同的服务, 在一起共同协作完成业务的需求, 微服务应运而生.

微服务 MicroService

简短来说, 微服务架构是一种以一些微服务来替代开发单个大而全应用的方法, 每一个小服务运行在自己的进程里,并以轻量级的机制来通信, 通常是 HTTP RESTful API. 微服务强调小快灵, 任何一个相对独立的功能服务不再是一个模块, 而是一个独立的服务.

举个例子, 就是将以前的大兵团全功能的部队, 拆分成一个一个专业化小分队, 各司其职, 各自为战, 彼此之间用清晰的接口通讯.

类似于真实世界, 以前推崇金字塔结构, 从上到下, 分层治理, 都在一个大的系统(进程)里以内部事件或函数调用的方法进行分工协作
现在呢, 更倾向于扁平化治理, 分成若干个独立运作的事业部(BU-Business Unit)或小组, 各自为战, 却又以API/RPC的方式紧密合作,为着一个或一些用户所需的产品服务

有一利就有一弊, 以往一个程序有几十个组件, 可能变成了有几十个micro service, 那么这么多micro service 如何管理呢?

类似于真实世界, 若干个小分队联合作战, 得有总参谋部协调, 彼此之间职责明确, 分工协作, 在软件世界中就有前端应用来具体调用和协调所依赖的微服务, 再加上服务注册service registery 和服务发现 service discovery 功能

"Unfortunately, there is no silver bullet. "
从来就没有包治百病的灵丹妙药, 如果有人声称有, 那一定是个骗子.
微服务的问题也不少, 小分队多了, 沟通成本就增加了, 性能也可能会有所下降

微服务架构的特征

Martin Fowler 在他的文章中总结了Micro Service的特点

围绕业务功能进行组织 Organized around Business Capabilities

不再是以前的纵向切分, 而改为按业务功能横向划分, 一个微服务最好由一个小团队针对一个业务单元来构建

做产品而非做项目 Products not Projects

不再是做一个个项目, 交付后就完事了, 而是做产品, 从设计编码到产品运维全过程掌控和负责 you build it, you run it

智能终端加简单通道 Smart endpoints and dumb pipes

基于resource的API,大量逻辑放在客户端, 服务器端着重于提供资源
Be of the web, not behind the web

去中心化管理 Decentralized Governance

自行其是, 自我管理, 不必在局限在一个系统里, 围绕着一个中心

去中心化数据管理 Decentralized Data Management

各人自扫门前雪, 自己管理和维护自己的数据, 各自之间互不直接访问彼此的数据, 只通过 API 来存取数据

基础设施自动化 Infrastructure Automation

每个微服务应该关注于自己的业务功能实现, 基础设施应该尽量自动化, 构建自动化,测试自动化, 部署自动化, 监控自动化

为应对失败而设计 Design for failure
- 设计之初就要考虑高可靠性High Availablity 和灾难恢复 Disaster Recover, 并考虑在错误监测和错误诊断方面如何着手
演进式设计 Evolutionary Design
- 没有完美的架构, 唯一不变的是变化, 要善于应对变化,容易改变其设计和实现, 因为其小,故而易变

微服务架构的特征和风格

特征

一个微服务的架构应该具有以下特征

�容易被替换和升级
比如以前用 Ruby 快速开发的原型可以由 Java 实现的微服务代替, 反正服务接口没变, 所以也没有什么影响
按功能单元组织服务
职责最好相对独立和完整, 以避免对其他服务过多的依赖和交互
微服务可选择最适合自己的技术方案
服务性质的不同影响技术的选型, 比如帐户的注册登录, 完成可以由 ruby on rails, python django 这些脚本框架来实现. 但是, 对于音视频流的编解码和处理, 最好用 C/C++ 甚至汇编语言来写. 其他的诸如数据库的选型, ORM 或 MVC 框架的选择, 都可以随机应变, 按照业务和技术的具体需求, 根据团队的技术栈和人员现状选择最适合的方案
架构由层次化转向扁平化
服务内部可以进行适当的分层, 服务之间尽量扁平化, 不要引入过多的层次

风格

短小精悍, 独立自治
只做一个业务并专注做好它
自动化部署和测试
相比大而全的单个服务, 微服务会有更多的进程, 更多的服务接口, 更多不同的配置, 如果不能将部署和测试自动化, 微服务所带来的好处会大大逊色
尽量减少�运维的负担
微服务的增多可能会导致运维成本的增加, 监控和故障诊断也可能会更困难, 所以要未雨绸缪, 在一开始的设计阶段, 就要充分考虑到如何及时的发现问题和解决问题
拥抱�失效与故障
微服务的高可靠性设计和防错性设计是与生俱来的, 分布在不同的机器,地域上的服务的硬件,网络等随时有可能出问题, 而这些问题要对服务质量没有任何影响
每个服务都是灵活易变, 可伸缩,可扩展, 可组合的�
微服务为应对变化提供了更多的可能, 就象乐高积木, 可以随意增减组合, 堆积出来不同的产品