[Java复习] 微服务

1. 怎么样定义一个微服务，或划分服务比较合理？业务导向的共性？

对应服务拆分，先设计高内聚低耦合的领域模型(DD)，再实现相应的分布式系统是一种比较合理的方式。

微服务是手段，不是目的。目的是为了让系统更容易扩展，富有弹性，支持高并发，高可用，易于运维等等。

使用DDD(领域驱动建模)进行业务建模，从业务中获取抽象的模型（例如用户，订单），根据模型的关系进行划分界限上下文。

界限上下文可理解为逻辑上得微服务，或单体应用中一个组件。

界限上下文评审原则：

原则1：上下文之间相互依赖越少越好，依赖上游不应该知道下游信息。（订单依赖商品，商品不应该知道订单信息）

原则2：使用潜在业务进行适配，如果能在一定程度响应业务变化，则证明该微服务可以在相当长一段时间内支撑应用开发。

从DDD的界限上下文往微服务转化，并得到系统架构、API列表、集成方式等。

设计微服务依赖关系

被依赖的服务不需要知道调用方的信息，否则就不是一个合理的依赖。

例如，用户服务对于访问他的来源不应该知晓，应该对订单、商品、物流等调用方提供无差别的服务。

设计微服务的集成方式

• 采用PRC远程调用方式集成（Dubbo, gRPC, Thrift等，耦合高）
• 采用消息的方式集成（异步传输，订阅-发布）
• 采用RESTful方式集成（HTTP协议，耦合低）

（拆分微服务是一个过程，内部高内聚，外部的解耦。要半年到一年才根据对业务的深入理解进行合理的划分设计微服务。）

2. 为什么会有Dubbo和Spring Cloud两个微服务框架的存在，各自的优势？最重要的区别？

Dubbo：远程服务调用的分布式框架，专注RPC领域。

特点：1. 远程通讯：长连接，NIO通讯，支持多种序列化(Hessian 2/ProtoBuf)，请求-响应模式交换信息。

2. 集群容错：提供基于接口的RPC，负载均衡，失败容错(failover/failback)，地址路由，动态配置等。

3. 自动发现：基于注册中心目录服务，服务消费者能动态查找服务提供者，地址透明，服务提供者可以平滑扩容缩容。

Spring  Cloud：微服务全面解决方案，全家桶，服务注册与发现，网关路由，负载均衡，服务间调用，服务保护断路器，分布式配置管理，分布式链路追踪，分布式消息传递等。

区别1：

Spring Cloud和Dubbo的最大区别： Dubbo是RPC通信，Spring Cloud是基于HTTP的REST方式。

各有优劣。

因为 Dubbo 采用单一长连接和 NIO 异步通讯（保持连接/轮询处理），使用自定义报文的 TCP 协议，并且序列化使用定制 Hessian2 框架，二进制传输，占用带宽少。适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况，但不适用于传输大数据的服务调用。而 Spring Cloud 直接使用 HTTP 协议（但也不是强绑定，也可以使用 RPC 库，或者采用 HTTP 2.0 + 长链接方式（Feign可以灵活设置），JSON报文，消耗大。

Dubbo的RPC痛点：

• 服务提供方和调用方接口依赖太强。
• 服务平台敏感，难以简单复用。

区别2：

Dubbo强依赖阿里，社区更新不及时，现在又开始更新，未来会不会停，不好说。

Spring Cloud: Spring社区，开源社区活跃。基于Spring boot，快速开发部署，方便测试。