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，快速开发部署，方便测试。
