• 微服务并非它的体积足够小，而是它的责任足够单一，很多人误解了「微」的真实含义，认为服务拆分得足够小就是微服务了，其实并非这样。此外，「微」还有“微不足道”的意思，也就是说，某个服务出现故障，它不会影响整个系统。

  • 微服务并非细粒度服务的组合，也就是说，粒度要细到什么程度，这取决于对业务功能的把控能力。此外，微服务是一种架构思想，包括看得见的微服务，还包括看不见的基础设施和自动化技术作为支撑。

  • 目前市面上常用的微服务架构dubbo+zk，spring cloud

  • 微服务的核心：注册中心（Service Registry）、服务提供方（service provider）、服务消费方（service consumer）。不过现在为了方便，又提出了网关的（service gateway）的概念，配动自动完成服务的注册和发现。

  • 从什么角度能区分出或者划分微服务和 RPC 分布式之间的区别或者关系？

微服务是一种应用架构模式，而 RPC 是一种远程调用方式，它们是不一样的概念；而在微服务中会出现服务之间的调用，为了确保性能，我们一般采用 RPC 来调用。

  • 微服务实现系统的模块化，便于公共模块复用和水平扩展，但目前的系统规模其实都很小，这种情况是不是不适合使用微服务？

我认为微服务架构用于业务较复杂或目前业务简单但将来有可能变得复杂的架构，建议视具体情况来确定合理的架构，不要为了微服务而去微服务。

  • 微服务与 SOA 到底有什么区别，各自的应用场景是什么？到底在什么样的情况才适合使用微服务架构？

微服务是SOA的一种轻量级的解决方案，其本质还是SOA，只是更容易落地而以。

对于满足以下条件可以考虑使用微服务：

1. 应用变得越来越大
2. 项目存在多种开发语言
3. 经典架构模式太重
4. 修改一个bug需要平滑升级
5. 需要对系统细粒度监控
6. 提升系统可用性，如果一个系统挂了，不会对整个业务产生致命影响

  • 服务与服务之间的事务怎么做？

在微服务架构中，建议尽量避免服务之间的调用，因此服务粒度的切分是至关重要的；服务间的调用会产生分布式事务问题，建议采用“最终一致性”方法来确保分布式事务，业界有两种常用做法：CQRS 和 Event Sourcing。

  • 如何使用事务补偿模式解决分布式事务问题？

事务补偿机制说简单点就是，在应用程序中通过代码的方式做到数据的还原。一般情况下，我们需借助消息队列与日志追踪等方式来实现。

  • 微服务在事务控制方面、容错方面有什么较好的实践方式？

1、微服务的事务控制本质上是分布式事务控制，建议使用“最终一致性”来确保。
2、在容错方面，需要有基础设施平台的支撑，比如服务网关的熔断机制

  • 微服务拆分有没有什么原则要点？

1. 微服务业务拆分可按整体业务组件来拆分，也可按单一业务功能来切分。建议切分步骤从粗到细，逐步细化，否则开始就过细，导致依赖性太高，增加复杂度。
2. 拆分服务时需降低彼此之间的耦合性，尽可能一个服务只做一件事情，即“单一职责原则”。

  • 怎样来控制微服务的粒度？就是有没有什么样的原则和最佳实践来判断一个功能（接口）是应该属于 A 服务还是应该属于 B 服务。

微服务的粒度控制取决于我们对业务的理解与把控能力，一切所谓的原则都是不靠谱的。

微服务需要考虑服务多版本问题，尤其是服务升级时，需要做到平滑，对整体系统没有任何影响。