什么是分布式系统
从进程角度看, 两个程序分别运行在两台主机的进程上, 它们相互协作最终完成同一个服务, 那么理论上这两个程序所组成的系统, 可以称作 ” 分布式系统 ”.
当然, 这两个程序可以是不同的程序, 可以是相同的程序. 如果是相同的程序, 我们又可以称为 “ 集群 ”. 所谓集群, 就是将相同的程序, 通过不断横向扩展, 以提高服务能力的方式.
应用框架演进
服务化架构
上图的 web app 服务是单体化的, 所有组件耦合在一个开发项目中, 并且配置和运行在一个 JVM 进程中. 如果某个组件需要升级上线, 则会导致其他没有变更的组件同样上线.
而且无法满足高并发请求处理, 水平扩展能力也很有限的.
为了解决上述问题, SOA 出现了. SOA 代表面向服务的架构, 俗称服务化. SOA 将应用程序的模块化组件通过定义明确的接口和协议联系起来, 接口是采用中立的方式进行定义的, 独立于某种语言、硬件和操作系统, 通常通过网络通信来完成, 但是并不局限于某种网络协议, 可以是底层的 TCP/IP, 可以是应用层的 HTTP, 也可以是消息队列协议, 甚至可以是来约定的某种数据库存储信息.
这使得各种各样的系统中的模块化组件可以以一种统一和通用的方式进行交互.
SOA 将模块化组件从单一进程中进一步拆分, 通过某种网络协议形成独立的对外提供服务的网络化组件, 这种架构下的特点如下:
SOA 定义了良好的对外接口, 通过网络协议对外提供服务, 服务之间表现为松耦合性.
某个服务的内部结构和实现发生改变时, 只要接口保持不变, 不影响整个流程对外提供服务.
SOA 通过定义标准的对外接口, 可以让多个使用方同时使用, 增加服务的可重用性.
SOA 可以让企业最大化地使用内部和外部地公共服务, 避免重复造轮子.
要彻底理解 SOA 时代地服务化发展情况, 我们必须理解 SOA 的两个主流实现方式: web service 和 ESB.
Web Service
Web Service 技术是 SOA 服务化的一种实现方式. 运行在不同操作系统上的服务的互相发现和调用, 并且可以通过某种协议交换数据.
上图可以看到, 每个服务之间是对等的, 并且互相是解耦的, 通过 WSDL 定义的服务发现接口进行访问, 并通过 SOAP 协议进行通信. SOAP 协议通常是一种在 HTTP 或者 HTTPS 通道上传输 XML 数据来实现的协议, 但是每个服务都要依赖中心化 Web Service 目录来发现现存的服务.
Web Service 的工作原理如下.
服务提供者 Web Service 2 和 Web Service 3 通过 UDDI 协议将服务注册到 Web Service 目录服务中.
服务消费者 Web Service 1 通过 UDDI 协议从 Web Service 目录中查询服务, 并获得服务的 WSDL 服务描述文件.
服务消费者 Web Service 1 通过 WSDL 语言远程调用和消费 Web Service 2 和 3 提供的服务.
通过这个过程, 要改造一个新的业务流程, 可以从 Web Service 目录中发现现有的服务, 并最大限度地重用现有的服务.
从服务化到微服务
随着物联网企业的不断发展, 互联网产品需要服务的用户量逐渐增加, 海量用户发起的大规模、高并发请求是企业不得不面对的.
前面介绍的 SOA 服务化系统能够分解任务, 让每个服务更简单、职责单一、更易于扩展, 但无论是 Web Service 还是 ESB, 都有时代遗留问题.
Web Service 的问题如下:
依赖中心化的服务发现机制.
使用 SOAP 通信协议, 通常使用 XML 格式来序列化通信数据, XML 格式的数据冗余太大, 协议太重.
服务化管理和治理设施并不完善.
微服务架构倡导将软件应用设计成多个可独立开发、可配置、可运行和可维护的子服务, 子服务之间通过良好的接口定义通信机制, 通常使用 RESTful 风格的 API 形式来通信, 因为 RESTful 风格的 API 通常是在 HTTP 或者 HTTPS 通道上传输 JSON 格式的数据来实现的, HTTP 协议有跨语言、跨异构系统的优点.
当然, 也可以通过底层的二进制协议、消息队列协议等进行交互.
这些服务不需要中心化的统一管理, 每个服务的功能可以自治, 并且可以由不同的语言、系统和平台实现.
微服务架构与传统单体架构的对比
上图我们可以得出如下结论:
微服务把每个职责单一的功能放在一个独立的服务中.
每个服务运行在一个单独的进程中.
每个服务有多个实例在运行, 每个实例可以运行在容器化平台内, 达到平滑伸缩的效果.
每个服务有自己的数据存储, 实际上, 每个服务又该有自己独享的数据库、缓存、信息队列等资源.
每个服务应该有自己的运营平台, 以及独享的运营人员, 这包括技术运维和业务运营人员; 每个服务都高度自治, 内部的变化对外透明.
每个服务都可以根据性能需求独立的进行水平伸缩.
通过对比微服务与传统单体架构, 我们得知传统单体架构具有如下特点:
传统单体架构将所有模块化组件混合后运行在同一个 JVM 进程中.
可对包含多个模块化组件的整体 JVM 进程进行水平扩展, 而无法对某个模块化组件进行水平扩展.
某个模块化组件发生变化时, 需要所有模块化组件进行编译、打包、和上线.
久而久之, 模块之间的依赖将会不清晰, 互相耦合、相互依赖成为家常便饭.
微服务架构与 SOA 服务化的对比
微服务在 SOA 服务化的基础上进行演进和叠加, 形成了适合现代化应用场景的一个方法论.
1. 目的不同
SOA 服务化涉及的范围更广一些, 强调不同的异构服务之间的协作和协议, 并强调有效集成、业务流程编排、历史应用集成等, 典型代表 Web Service 和 ESB.
微服务使用一系列的微小服务来实现整体的业务流程, 目的是有效的拆分应用, 实现敏捷开发和部署, 在每个微小服务的团队里, 减少了跨团的沟通, 让专业的人做专业的事, 缩小变更和迭代影响的范围, 并达到单一微服务更容易水平扩展的目的.
2. 部署方式不同
微服务将完整的应用拆分成多个细小的服务, 通常使用敏捷扩容、缩容的 Docker 技术来实现自动化的容器管理, 每个微服务运行在单一的进程内, 微服务中的部署互相独立、互不影响.
SOA 服务化通常将多个业务服务通过组件化模块方式打包在一个 war 包里, 然后统一部署在一个应用服务器上.
3. 服务粒度不同
微服务倡导将服务拆分成更细的粒度, 通过多个服务组合来实现业务流程的处理, 拆分到职责单一, 甚至小到不能再进行拆分.
SOA 对粒度没有要求, 在实战中服务通常是粗粒度的, 强调接口协议的规范化, 内部实现可以更粗颗粒.
总结
微服务是新一代分布式架构.
每个服务运行在单一的进程内, 独立部署、互不影响.
每个服务拆分到职责单一、甚至小到不能在拆分.
每个服务有自己独享的数据库、缓存、信息队列等资源.
每个服务有自己的运营平台; 每个服务都高度自治, 内部的变化对外透明.
每个服务可以通过 HTTP 或底层的二进制协议、消息队列协议等进行交互.