SpringCloud(1)-微服务
微服务架构的四个核心问题
- 服务很多，客户端该怎么访问？
- 这么多服务，服务间如何通信？
- 这么多服务，如何治理？
- 服务挂了怎么办？
解决方案
SpringCloud 生态
1. Spring Cloud Netflix ：一站式解决方案。
API网关：zuul组件
通信：Feign---HttpClient---Http通信方式（同步，阻塞）
服务注册与发现：Eureka
熔断机制：Hystrix
2. Apache Dubbo Zookeeper ：半自动，需要整合别人的。
API网关：无
通信：Dubbo
服务注册与发现：Zookeeper
熔断机制：无
3. Spring Cloud Alibaba ：一站式解决方案。
--------------------------------------------------------------------------------
万变不离其宗：
1. API
2. HTTP,RPC
3. 服务注册与发现
4. 熔断机制
--------------------------------------------------------------------------------
为什么要解决这四个问题？
网络不可靠！
什么是微服务架构
微服务架构是一种架构模式，或者说是一种架构风格，它提倡将单一的应用程序划分为一组小的服务（将整体划分为一个个服务，模块化），每个服务在其独立的自己的进程内（每个服务都是一个进程），进程之间相互协调，相互配置，为用户提供最终价值。服务之间采用轻量级的通信机制（Http）相互沟通，每个服务都围绕着具体业务进行构建，并且能够独立的部署到生产环境中，另外，应尽量避免统一的、集中式的服务管理机制（服务注册与发现机制），对于一个服务而言，应根据业务上下文，选择合适的语言，工具对其进行构建（Maven），可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。
微服务架构的核心就是将传统的一站式应用（All In One），根据业务拆分成一个一个的服务，彻底地解耦，每一个微服务提供单个业务功能，一个服务就做一件事，类似进程的概念，能够单独启动或销毁，拥有自己独立的数据库。
Martin Fowler关于微服务的原文：https://martinfowler.com/articles/microservices.html
微服务优缺点
优点：
- 每个服务高内聚，并且小，代码容易理解，可以聚焦一个指定的业务功能或业务需求。
- 开发简单，开发效率高，一个服务可能就是专一的只干一件事，单一职责原则。
- 能够被小团队单独开发，小团队可能是2-5人。
- 低耦合，无论是在开发阶段还是部署阶段都是独立的。
- 可以使用不同的语言开发。
- 易于被一个开发人员理解、修改和维护，这样小团队能够更多关注自己的工作成果，无需通过合作才能体现价值。
- 只是业务逻辑代码，不会与HTML、CSS或其他界面混合。
- 每个服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库。
缺点：
-
开发人员要处理分布式系统的复杂性。
-
随着服务的增加，管理复杂度增加，增加了运维难度。
-
服务间通信成本。
-
数据一致性。
微服务的技术栈
| 微服务条目 | 落地技术 |
|---|---|
| 服务开发 | SpringBoot，Spring，SpringMVC |
| 服务配置与管理 | Netflix的Archaius，阿里巴巴的Diamond |
| 服务注册与发现 | Eureka，Consul，Zookeeper |
| 服务调用 | Rest，RPC，gRPC |
| 服务熔断 | Hystrix，Envoy |
| 负载均衡 | Ribbon，Nginx |
| 服务接口调用 | Fegin |
| 消息队列 | Kafka，RabbitMQ，ActiveMQ |
| 服务配置中心管理 | SpringCloudConfig，Chef |
| 服务路由（API网关） | Zuul |
| 服务监控 | Zabbix，Nagios，Metrics，Specatator |
| 全链路追踪 | Zipkin，Brave，Dapper |
| 服务部署 | Docker，OpenStack，Kubernetes |
| 数据流操作开发包 | SpringClould Stream |
| 事件消息总栈 | SpringCloud Bus |