什么是微服务?
目前的微服务并没有一个统一的标准，一般是以业务来划分
将传统的一站式应用，拆分成一个个的服务，彻底去耦合，一个微服务就是单功能业务，只做一件事。
微服务与微服务架构
微服务是一种架构模式或者一种架构风格，提倡将单一应用程序划分成一组小的服务==独立部署==，服务之间相互配合、相互 协调，每个服务运行于自己的进程中。
服务与服务间采用轻量级通讯，如HTTP的RESTful API等
避免统一的、集中式的服务管理机制
微服务的优缺点:
优点
每个服务足够内聚，足够小，比较容易聚焦
开发简单且效率高，一个服务只做一件事情
开发团队小，一般2-5人足以（当然按实际为准）
微服务是松耦合的，无论开发还是部署都可以独立完成
微服务能用不同的语言开发
易于和第三方集成，微服务允许容易且灵活的自动集成部署（持续集成工具有Jenkins,Hudson,bamboo等）
微服务易于被开发人员理解，修改和维护，这样可以使小团队更加关注自己的工作成果，而无需一定要通过合作才能体现价值
微服务允许你融合最新的技术
==微服务只是业务逻辑的代码，不会和HTML,CSS或其他界面组件融合==。
==每个微服务都可以有自己的存储能力，数据库可自有也可以统一，十分灵活==。
缺点
开发人员要处理分布式系统的复杂性
多服务运维难度，随着服务的增加，运维的压力也会增大
依赖系统部署服务间通讯的成本
数据的一致性
系统集成测试
性能监控的难度
微服务的技术栈：
| 微服务条目 | 落地技术 |
| 服务开发 | SpringBoot,Spring,SpringMVC |
| 服务配置与管理 | Netflix公司的Archaius、阿里的Diamond等 |
| 服务注册与发现 | Eureka、Consul、Zookeeper等 |
| 服务调用 | Rest、RPC、gRPC |
| 服务熔断器 | Hystrix、Envoy等 |
| 负载均衡 | Ribbon、Nginx等 |
| 服务接口调用（客户端调用服务的简化工具） | Feign等 |
| 消息队列 | Kafka、RabbitMQ、ActiveMQ等 |
| 服务配置中心管理 | SpringCloudConfig、Chef等 |
| 服务路由（API网关） | Zuul等 |
| 服务监控 | Zabbix、Nagios、Metrics、Specatator等 |
| 全链路追踪 | Zipkin、Brave、Dapper等 |
| 服务部署 | Docker、OpenStack、Kubernetes等 |
| 数据流操作开发包 | SpringCloud Stream(封装与Redis，Rabbit，Kafka等发送接收消息) |
| 事件消息总线 | SpringCloud Bus |
微服务中SpringCloud与Dubbo的区别
| Dubbo |
Spring | |
| 服务注册中心 | Zookeeper | Spring Cloud Netfilx Eureka |
| 服务调用方式 | RPC | REST API |
| 服务监控 | Dubbo-monitor | Spring Boot Admin |
| 断路器 | 不完善 | Spring Cloud Netflix Hystrix |
| 服务网关 | 无 | Spring Cloud Netflix Zuul |
| 分布式配置 | 无 | Spring Cloud Config |
| 服务跟踪 | 无 | Spring Cloud Sleuth |
| 消息总线 | 无 | Spring Cloud Bus |
| 数据流 | 无 | Spring Cloud Stream |
| 批量任务 | 无 | Spring Cloud Task |
最大区别：
Spring Cloud抛弃了RPC通讯，采用基于HTTP的REST方式。Spring Cloud牺牲了服务调用的性能，但是同时也避免了原生RPC带来的问题。REST比RPC更为灵活，不存在代码级别的强依赖，在强调快速演化的微服务环境下，显然更合适。
==一句话：Dubbo像组装机，Spring Cloud像一体机==
社区的支持与力度：Dubbo曾经停运了5年，虽然重启了，但是对于技术发展的新需求，还是需要开发者自行去拓展，对于中小型公司，显然显得比较费时费力，也不一定有强大的实力去修改源码
总结
解决的问题域不一样：Dubbo的定位是一款RPC框架，Spring Cloud的目标是微服务架构下的一站式解决方案 ；