微服务是继SOA以后流行起来的一种系统架构模式。因它紧随SOA以后,因此有必要对他们先做个比较。react
关于两者的比较表格,我在谷歌上搜索的一篇文章分析的挺好,现引用以下。git
面向服务架构 | 微服务架构 |
---|---|
出现于1990's年代 | 出现于2000's年代 |
最大化应用服务的重用性 | 关注解耦 |
系统变化须要修改总体 | 系统变化是建立新服务 |
DevOps和持续发布开始变得流行但不是主流 | 重点关注DevOps和持续发布 |
聚焦于业务系统重用 | “边界上下文”愈加重要 |
使用ESB通讯 | 使用简单消息系统通讯 |
支持多种消息协议 | 使用轻量级协议诸如:HTTP, REST等 |
对部署在其上的全部服务使用通用平台 | 一般使用云平台而非应用服务器 |
Docker不太流行 | 容器与微服务工做的很是协调 |
SOA服务共享数据存储 | 每一个微服务能够拥有独立的存储服务 |
通用的治理和标准 | 松散治理,关注团队协做与自由选择 |
<!--more-->github
微服务这么流行,确定有其优点所在。不过也不能不看到它的劣势噢。spring
如何扬长避短,更好更方便地利用微服务呢。数据库
统一配置中心。编程
服务发现后端
一个事件总线,利用分布式消息系统将服务和服务实例连到一块儿。可用于在集群内传播状态变化(如配置变化事件)api
集成你的应用到Pivotal Cloud Foundry,提供而且让实现SSO和OAuth2来保护资源变得更加容易。服务器
提供一个用于构建实现了Open Service Broker API的服务的Broker的起始点架构
Open Service Broker API链接开发者到一个全球的服务生态环境,该项目给开发者、ISVs、SaaS厂商提供一个单一的、简单的和完美的方式去发布服务到原生云平台上(诸如Cloud Foundry, OpenShift, Kubernetes)
提供基于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://www.yesdata.net/2018/03/15/microservice-and-spring-cloud/
·