微服务概述
1.微服务的4个核心问题
- 服务很多，客户端怎么访问？
- 这么多服务，服务之间如何通信？
- 这么多服务，如何治理？
- 某个服务挂了怎么办？
2.解决方案
2.1、SpringCloud NetFlix： 一站式解决方案（能解决以上的4个问题）
- 客户端怎么访问：api网关，zuul组件
- 服务之间如何通信：Feign（基于HttpClinet，即Http通信方式）
- 服务注册与发现：Eureka
- 熔断机制：Hystrix
2.2、Dubbo + Zookeeper：半自动，需要整合别的东西。
- 客户端怎么访问：无api网关，找第三方组件，或自己实现。
- 服务之间如何通信：Dubbo
- 服务注册与发现：Zookeeper
- 熔断机制：借助 Hystrix
- 总结：Dubbo这个方案并不完善。（但其是专业的RPC框架）
2.3、SpringCloud Alibaba：更简单的一站式解决方案
- 与SpringCloud NetFlix差不多，但是比它更简单
2.4、新概念：服务网格（Server Mesh），被称为下一代的微服务标准。
- 解决方案：istio
3.微服务的基础（万变不离其宗）
- API网关：解决服务路由的问题。
- Http，RPC：解决通信问题
- 服务的注册和发现：解决高可用问题
- 熔断机制：解决服务降级的问题。
4.什么是微服务
就目前而言,对于微服务,业界并没有一个统一的,标准的定义。
但通常而言,微服务架构是一种架构模式,或者说是一种架构风格，它提倡将单一的应用程序划分成一组小的服务（模块化），每个服务运行在其独立的自己的进程内（模块化后可以拼装），服务之间互相协调,互相配置,为用户提供最终价值。
服务之间采用轻量级的通信机制互相沟通（也就是Http或者RPC），每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境中（相当于每个服务都有自己的端口，都是一个进程而不是线程）。
另外，应尽量避免统一的，集中式的服务管理机制（所以有了一些分布式的服务注册和发现的机制）。
对具体的一个服务而言，应根据业务上下文，选择合适的语言，工具对其进行构建，（一般用maven进行构建）。
可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务（最后都可以用一个轻量级的通讯机制进行沟通），也可以使用不同的数据库（可以在关系型数据库存东西也可以在非关系型数据库）。
从技术维度理解：
- 微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合。每一个微服务提供单个业务功能的服务，一个服务做一件事情。从技术角度看就是一种小而独立的处理过程，类似进程的概念，能够自行单独启动或销毁，拥有自己独立的数据库。
5.微服务与微服务架构
微服务：
强调的是服务的大小,他关注的是某一个点,是具体解决某一个问题/提供落地对应服务的一个服务应用。可狭义地看作是IDEA中的一个个微服务工程，或者Moudel。（application去启动的 端口不同的服务）
IDEA工具里面使用Maven开发的一个个独立的小Moudle,它具体是使用springboot开发的一个小模块,专业的事情交给专业的模块来做,一个模块就做着一件事情。
强调的是一个个的个体,每个 个体完成一个具体的任务或者功能!
微服务强调的是个体，而微服务架构不同，这是两个概念不要搞混
微服务架构：
微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调,互相配合,为用户提供最终价值。
每个服务运行在其独立的进程中,服务于服务间采用轻量级的通信机制互相协作,每个服务都围绕着具体的业务进行构建,并且能够被独立的部署到生产环境中,另外,应尽量避免统一的,集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言,工具对其进行构建。
微服务架构是要去解决文章开始提出的那四个问题的，而微服务只是其中的一个组件而已。
微服务要把很多服务组合起来才变成一个真正的服务
6.微服务优缺点优点：
优点：
符合单一职责原则。
每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或业务需求。
开发简单，开发效率提高，一个服务可能就是专一的只干一件事。
微服务能够被小团队单独开发，这个小团队是2-5人的开发人员组成。
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
微服务能使用不同的语言开发。
易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如jenkins， Hudsonbamboo。
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
微服务允许你利用融合最新技术。
微服务只是业务逻辑的代码，不会和HTML， css或其他界面混合。
每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。
缺点：
- 开发人员要处理分布式系统的复杂性。
- 多服务运维难度，随着服务的增加，运维的压力也在增大（本来all in one就水平的负载均衡就好了，现在可能要几十个上百个服务，一个一个包去发布）。
- 系统部署依赖。
- 服务间通信成本变高。
- 数据有可能不一致性。
- 系统集成测试。
- 性能监控…
7.微服务的技术栈有哪些
一部分：
| 微服务条目 | 落地技术 |
|---|---|
| 服务开发 | SpringBoot，Spring，SpringMVC |
| 服务配置与管理 | Netflix公司的Archaius、阿里的Diamond等 |
| 服务注册与发现 | Eureka， Consul， Zookeeper等 |
| 服务调用 | Rest（RestFul风格）， RPC， gRPC（谷歌的RPC） |
| 服务熔断器 | Hystrix. Envoy等 |
| 负载均衡 | Ribbon， Nginx等 |
| 服务接口调用(客户端调用服务的简化工具) | Feign等 |
| 消息队列 | Kafka， RabbitMQ ActiveMQ等 |
| 服务配置中心管理 | SpringCloudConfig， Chef等（远程配置，配置可以放在github上） |
| 服务路由(API网关) | Zuul等 |
| 服务监控 | Zabbix. Nagios， Metrics， Specatator等 |
| 全链路追踪 | Zipkin. Brave， Dapper等 |
| 服务部署 | Docker（主要学这个）. OpenStack， Kubernetes等 |
| 数据流操作开发包 | SpringCloud Stream(封装与Redis， Rabbit， Kafka等发送接收消息) |
| 事件消息总线 | SpringCloud Bus |
8.为什么要选择SpringCloud作为微服务的架构
1、选型依据：
- 整体解决方案和框架成熟度
- 社区热度（比如GitHub更新频率高）
- 可维护性
- 学习曲线（学习使用难度并不高，只需要几个注解就行了，但是要精通还可以更加深入学习）
2、当前各大IT公司用的微服务架构有哪些：
- 阿里： dubbo+HFS
- 京东： JSF
- 新浪： Motan
- 当当网：Dubbox
