本文共 2582 字,大约阅读时间需要 8 分钟。
微服务是继SOA之后流行起来的一种系统架构模式。因它紧随SOA之后,所以有必要对他们先作个比较。
关于二者的比较表格,我在谷歌上搜索的一篇文章分析的挺好,现引用如下。
面向服务架构 | 微服务架构 |
---|---|
出现于1990's年代 | 出现于2000's年代 |
最大化应用服务的重用性 | 关注解耦 |
系统变化需要修改整体 | 系统变化是创建新服务 |
DevOps和持续发布开始变得流行但不是主流 | 重点关注DevOps和持续发布 |
聚焦于业务系统重用 | “边界上下文”越发重要 |
使用ESB通信 | 使用简单消息系统通信 |
支持多种消息协议 | 使用轻量级协议诸如:HTTP, REST等 |
对部署在其上的所有服务使用通用平台 | 通常使用云平台而非应用服务器 |
Docker不太流行 | 容器与微服务工作的非常协调 |
SOA服务共享数据存储 | 每个微服务可以拥有独立的存储服务 |
通用的治理和标准 | 松散治理,关注团队协作与自由选择 |
微服务这么流行,肯定有其优势所在。不过也不能不看到它的劣势噢。
如何扬长避短,更好更方便地利用微服务呢。
统一配置中心。
服务发现
一个事件总线,利用分布式消息系统将服务和服务实例连到一起。可用于在集群内传播状态变化(如配置变化事件)
集成你的应用到Pivotal Cloud Foundry,提供并且让实现SSO和OAuth2来保护资源变得更加容易。
提供一个用于构建实现了Open Service Broker API的服务的Broker的起始点
Open Service Broker API连接开发者到一个全球的服务生态环境,该项目给开发者、ISVs、SaaS厂商提供一个单一的、简单的和完美的方式去发布服务到原生云平台上(诸如Cloud Foundry, OpenShift, Kubernetes)
Open Service Broker 项目
Open Service Broker API定义
提供基于Zookeeper、Redis、Hazelcast、Consul的领头选举、通用状态机模式的抽象及实现。
基于Hashicorp Consul的服务发现及配置管理。
提供对基于负载均衡的OAuth2 rest client和authentication header的支持,依赖了Zuul proxy。
应用于Spring Cloud的分布式追踪功能,与Zipkin, HTrace and log-based (e.g. ELK) tracing 相兼容。
一个cloud-native的服务编排,易用的DSL、drag-and-drop GUI,REST-APIs 一起全面简化了基于服务编排的数据管道。
一个轻量级的事件驱动微服务框架,便于快速构建连接到外部系统的应用。简单的声明模型可以使用Apache Kafka或RabbitMQ在Spring Boot应用间收发消息。
一系列基于Spring Boot的Spring集成应用程序,提供与外部应用的集成。
一个短期的微服务框架,快速构建执行有限数量的数据处理的应用。简单的声明就可以增加功能性或非功能性特性到Spring Boot中。
一系列单机版的可执行应用程序,可以拥有按需用例:比如数据库迁移、机器学习、定时操作。这些应用可以运行于各种独立平台,比如:Cloud Foundry、Apache Yarn、 ApacheMesos、Kubernetes、Docker甚至你的笔记本上。
基于Apache Zookeeper的服务发现及配置管理。
使得运行于各种平台上的PaaS应用能够方便地连接到后端服务,比如数据库、消息Broker。(这个项目原先叫作Spring Cloud)
Spring Boot风格的启动项目,简化服务消费方Spring Cloud的依赖管理。
Spring Boot CLI插件,用来快速使用Groovy语言创建Spring Cloud组件应用
是一揽子有关帮助用户成功地实现“消费端驱动契约”方式解决方案
是一款基于智能的、可编程的路由的Project Reactor
为Spring Boot应用提供通过自动化配置和绑定到Spring Environment和其它编程模型风格的集成。
原文发表于
·
转载地址:http://qvbuo.baihongyu.com/