阿里巴巴前架构师 360 度无死角剖析微服务

微服务是当前软件架构领域很是热门的词汇，在社区中也有不少热烈的讨论。所以，在 OSC 第 130 期高手问答中，咱们策划的主题是“究竟什么才是微服务”，并邀请了黄勇做为高手嘉宾。

黄勇，现任特赞公司 CTO，曾任阿里巴巴公司系统架构师。对微服务架构与大数据技术有深刻研究，具备丰富的网站架构设计经验与项目管理经验，擅长敏捷开发模式。国内开源软件推进者之一，活跃于“开源中国”社区网站，Smart 开源框架创始人，图书《架构探险：从零开始写Java Web框架》、《轻量级微服务架构（上册）》做者。热爱技术交流，乐于分享本身的工做经验与生活感悟。

微服务是近年来备受关注的话题，它的出现让咱们想起了十年前的 SOA（Service-Oriented Architecture，面向服务架构），但它比传统的 SOA 更容易理解，也更容易实践，它将“面向服务”的思想作得更加完全。

尤为是当国外的一些知名技术公司成功实践了微服务之后，这股热潮就吹遍了国内的大街小巷，咱们也看到不少的项目使用了微服务，但实际上依然有很多朋友对于微服务有着很多疑惑。

所以本篇文章，会介绍与微服务架构相关的一些基础概念、适用场景以及如何解决在实践中遇到的问题等内容。

1、与微服务相关的一些基本概念

我之前作过微服务，基本框架是 Spring MVC，微服务之间和微服务与平台之间的访问是经过在 Zookeeper 上的 Dubbo 通信的，请问这算是微服务吗？

其实微服务架构的范围是至关广的，这些我认为只是微服务架构的一部分。

如何更好理解【微服务】这个“微”字。从设计之初，开发，部署，运维，监控，等有什么地方（基于你的过往历程）须要关注的？

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

据说微服务是个很大的概念，Dubbo 只是实现了其中一小部分，请问完善的微服务架构是什么样的？Spring Cloud 是否算是完善的微服务？

微服务架构的范围比较大，Dubbo 和 Spring Cloud 都只是解决了微服务的一部分问题，并未彻底覆盖。

若是分布式服务原本拆分的颗粒度就比较细，每个模块都是独立的服务，可不可就理解为至关于微服务？

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

请问微服务的核心系统是什么？是微服务的发现和组织吗？每一个微服务很好作，如何把他们组合起来，有没有现成的系统能够参考？

1. 我认为微服务的核心是：服务注册中心（Service Registry）与服务网关（Service Gateway），它们配合完成服务注册与服务发现。
2. 将服务组合起来也成为“服务编排”，有多重作法，能够在服务网关中进行编排，也能够经过中间服务进行编排，我更倾向于后者，这样确保服务网关不包含任何业务，更加轻量级。

微服务比普通架构须要多作那些工做？OpenStack 的架构设计属于什么类型？微服务是否是须要更多的运行资源？

1. 微服务架构比传统架构更加依赖于对自动化运维的支持。
2. OpenStack 是一款云计算平台，为云计算的 IaaS 层提供了解决方案。
3. 在微服务架构中，须要相关的基础设施与不少独立运行的服务，我认为相比较传统架构而言，所消耗的硬件资源较高一些。但从如今来看，硬件资源的成本已经很是低了。

SOA、WebService、RESTful 这些概念有什么本质的区别。开发者日常使用的那些 AJAX、HTTP 接口（含 session 状态的）算得上 RESTful 接口吗？

1. RESTful 是一种架构风格，SOA 是一种架构思想，能够认为 RESTful 有助于 SOA 的落地化。
2. RESTful 通常应用在 HTTP 协议上，在先后端分离架构中，前端经过 AJAX 技术发送 RESTful HTTP 请求到后端，获取后端 JSON 数据，并进行界面渲染。一样，RESTful 也用于微服务架构中，每一个服务对外暴露 REST API 做为通讯接口。

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

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

是否有接触过“领域驱动的分析与设计方法(DDD)”，你是如何理解“DDD”与“微服务”之间关系的？

DDD 是基于领域对象的设计思想，微服务是基于服务的业务架构，DDD 与微服务可相辅相成。

公司如今用的是 Dubbo 框架，这是微服务框架仍是 SOA？记得有些博客说微服务去中心化，那这个中心是否是就是 Dubbo 里的注册中心？

1. Dubbo 从本质上来说属于微服务框架，它有服务注册与发现，也有服务之间不一样协议的通讯，以及服务调用的监控。而传统的 SOA 更倾向于使用 ESB 这类总线的方式来实现服务的注册与通讯，能够把 ESB 当作是一个中心，所以相对微服务而言，传统 SOA 更加剧量级一些。我认为微服务是 SOA 的一种轻量级实现，它的本质仍是 SOA。
2. 所谓去中心化，其实是确保不由于中心而致使单点故障，若是能解决这个问题，有中心又如何呢？所以，我认为不要一味地去中心化，要合理地去中心化才是正道。

2、什么场景下选择微服务？

微服务架构我以为比较适合新项目，若是用于已有项目那至关于要重构，或者逐步拆分作微服务架构？是否是这样？仍是有什么更好的方法？

1. 对于业务流程较为复杂，且业务会变得逐渐复杂的项目，能够考虑使用微服务架构。
2. 对于已有项目而言，可考虑逐步进行微服务化，也可考虑在新业务中使用微服务架构。

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

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

高并发低延迟的系统能使用微服务吗？

我认为高并发场景不太适合使用微服务，由于微服务会带来一些调用链的开销，高并发场景须要作到尽量地的延迟以及更高效的通信。

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

我认为微服务是 SOA 的轻量级解决方案，微服务的本质仍是 SOA，只是更加容易落地而已。

我认为在如下几种状况下，可考虑使用微服务架构：

• 应用变得愈来愈大时
• 项目存在多种开发语言时
• 感受到经典架构模式过重时
• 修改了一个 bug 须要平滑升级时
• 想对系统进行细粒度监控时

固然还有其余使用场景，但微服务不是万灵丹，不能适用于全部场景。并且微服务对运维是有必定的要求的，尤为是自动化运维。即使业务目前比较简单，但未来会变得复杂，也建议使用微服务架构。

3、如何考量微服务的技术选型？

微服务的开源技术选型能介绍几种吗？Spring Cloud 如何解决跨语言的问题呢？

比较知名的微服务开源技术选型莫过于 Spring Cloud，它对 Netflix 提供的相关组件作了必定的封装，让开发者更容易上手。固然，我更加但愿本书所先介绍的开源技术选型会被更多人接受与应用。

此次你的这本关于轻量级微服务，我有几个问题，你的这本书里关于微服务的技术选型是怎么考量的？书中提到了 Spring Boot，你对于 Spring 的这个技术怎么看？如今微信小程序比较流行，微服务会成为小程序的技术首选吗？

1. 这本书中关于微服务的技术选型问题，我作了大量的思考并实践，所选择的方案均为开源，且很是轻量级，目的是帮助你们可以快速搭建这款轻量级微服务架构。
2. 虽然这本书讲到的微服务开发框架是 Spring Boot，用过的人都知道它有明显的优点，固然也有明显的劣势，毕竟底层仍是基于 Spring，而 Spring 从当初的轻量级彷佛变得愈来愈重，我但愿有更好的轻量级框架能够出现，因此当初写了一款 Smart 框架以及《架构探险》第一本书，目的只是抛砖引玉，但愿有更多的朋友都能投身到国内开源行业中，创造更优秀的开源项目。
3. 我很是看好微信小程序的将来，但微服务是否成为小程序的技术首选，我不太敢下次评论，我们一块儿静观其变吧。

微服务框架是在 SOA 的基础上提出的吗？在技术选型要注意哪些点，用 Spring Cloud 仍是 Spring Boot？怎样作到轻量级，有哪些参考？

1. 我认为微服务是传统 SOA 的轻量级解决方案，它让 SOA 更加容易落地。
2. 在微服务技术选型方面，我建议竟可能地轻量级，作到“进可攻退可守”，至于 Spring Cloud 仍是其余框架，彻底取决于咱们对技术自己的理解以及对业务的把控能力，技术也业务须要相互结合才能产生价值。
3. 但愿这本书中所设计的轻量级开源方案，会帮助您更快地搭建微服务架构。

4、实施微服务的开发成本有多高？

该在多大规模的项目中使用微服务比较合适？微服务会增长架构复杂度吗？带来的收益是否能够抵消？

1. 我认为对于业务比较清晰的项目都可使用微服务架构，并不是须要具有多大规模。
2. 微服务架构会带来系统的复杂度（成本），但必然会带来一些收益，至于成本和收益是否低效，这取决于咱们对微服务与业务的理解与把控能力。

实施微服务后，对于开发成本是否是更高了？

我认为实施微服务并未提升开发成本，而是提升运维成本，一个好的微服务架构离不开运维方面的支持。本书下册将针对运维方面将以描述，敬请期待。

微服务通常都要用到 Docker，这样对研发人员和运维人员技术就要求更高了，如何快速有效实施微服务架构？

实施微服务必然会提升运维方面的成本，但我认为这是有价值的，尤为是自动化运维技术，也须要培养开发人员的运维思想。

微服务挺多人说玩不起，是否是相对来讲实施成本挺高的？

玩不起包括两层含义：一是认为成本较高；二是担忧有风险（怕玩挂了）。

5、微服务中的事务

如何简单有效的实现事务？

可以使用消息队列的方式，实现服务之间的事务控制。服务调用完毕，写入消息队列，经过消息驱动的方式调用其余服务。

服务间是否是应该避免相互间调用, 由 API Gateway 来组织各个服务？

没错，应该避免服务间的调用，而使用服务网关做为调用入口，但我不建议在服务网关处组织服务调用，而是经过一个中间服务来编排，或使用消息驱动方式来完成。

服务与服务之间的事务怎么作？

在微服务架构中，建议尽可能避免服务之间的调用，所以服务粒度的切分是相当重要的；服务间的调用会产生分布式事务问题，建议采用“最终一致性”方法来确保分布式事务，业界有两种经常使用作法：CQRS 和 Event Sourcing。

目前，微服务的事务是你们最关心的，微服务的分布式事务问题如何解决？请问，如今业界有没有开源的解决微服务事务的项目。

微服务的事务控制比较复杂，咱们须要作到尽量避免服务之间的调用，这取决于咱们对微服务切分的粒度控制。

微服务分布式事务通常借助消息驱动与日志追踪的方式来解决，以达成事务的“最终一致性”，业界有 CQRS 与 Event Sourcing 来解决微服务的事务问题，但愿对您有帮助。

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

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

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

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

6、微服务的业务该如何拆分？

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

微服务业务拆分可按总体业务组件来拆分，也可按单一业务功能来切分。建议切分步骤从粗到细，逐步细化，不然开始就过细，致使依赖性过高，增长复杂度。

一个大服务怎么拆最好，依据是什么，微服务拆分如何控制合适的粒度？另外如今的微服务的教程好像都是针对 Java 的，好比 Spring Boot，其余语言有没有成熟的体系？

建议从整个业务流程来分析，首先抽象出公共服务，而后采用大粒度的方式来切分，最后逐步细化切分粒度，微服务切分粒度取决于咱们对业务的理解与把控能力。其余开发语言也有相似于 Spring Boot 的微服务开发框架，好比 .NET 的 Nancy。

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

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

微服务目前对于各个功能拆分是否是有些太细？

我认为微服务的切分粒度没有必要太细，适合业务发展并能提升开发效率的架构才是好架构。

微服务拆分若是粒度太细，会不会致使维护成本增长？响应时间增长？事务控制如何实现？

1. 微服务粒度问题取决于咱们对业务的理解与把控能力，无需太细。
2. 可借用消息队列和日志追踪进行事务控制，也可以使用 CQRS 或 Event Sourcing 解决方案。

如何控制粒度在方法级别的接口的调用权限？

此处所描述的“接口”是否理解为服务的 API 接口呢？API 调用的权限控制可在微服务架构中的服务网关（Service Gateway）处加以控制。

单体架构拆分红微服务后，每一个服务能独立布署，也便于横向扩展，但也面临以下的问题：

1. 微服务拆分粒度的原则是？2. 微服务的服务治理？

1. 服务是根据业务功能来拆分的，拆分服务时需下降彼此之间的耦合性，尽量一个服务只作一件事情，即“单一职责原则”。
2. 服务治理问题所涉及的问题较多，将在这本书下册中加以描述，敬请期待，也欢迎进一步探讨。

服务拆分以后就会出现，微服务调用微服务的状况，致使效率很慢，接口的 QPS 很低，怎么解决？

个人建议是，尽量避免服务之间的调用，不妨使用消息队列的方式来下降服务之间的耦合，固然必要的直接调用可以使用 RPC 技术，它具有优秀的性能，可确保较高的 QPS。

7、使用微服务遇到的问题

我在公司实现分布式的过程当中遇到了 3 个问题，如您有时间请您给些思路：

1. 分布式事务：当前采用消息队列，队列的消费者使用 Redis 作分布式锁来实现幂等消费，不知道这种方式存在什么隐患？或者有没有更好的方式？
2. 日志聚合：目前想要作一个日志聚合功能，暂时考虑仍是使用消息队列处理，不知道有什么业界成熟的方式？
3. 方法调用次数统计，暂时咱们想使用 AOP + 消息队列 + strom 的方式来实现方法调用与耗时统计，不知道业界成熟的方式是什么？

1. 消息队列可用于分布式事务控制，这项技术已经在业界被证明是可用的。此外，还有 CQRS 与 Event Sourcing 技术也能够尝试一下。
2. 日志聚合可以使用业界流行的 ELK，即 Elasticsearch + Logstash + Kibana 来实现，L 用于收集日志，E 用于存储日志，K 用于展示日志。
3. 方法调用次数统计，不建议放在服务内部经过 AOP 来控制，建议在微服务架构的服务网关（Service Gateway）加以控制。

我以为接口调用次数统计，也能够结合 flume + Mq + strom 作实时统计，这样能够根据日志信息获取调用次数额外的东西，如调用者所在的地区等。

看具体要求是怎样的，若是只是简单记录 API 调用次数，可在服务网关处增长此功能，将结果记录到 MQ 中。

权限分访问权限与资源权限。想请教下资源权限在微服务中怎么作？好比我有个商品服务跟优惠服务，想要控制某个用户只能查询商品和建立优惠券，是每一个微服务都有独自的权限功能，仍是有个权限服务统一下发和调配各个微服务的权限？或者贵公司在微服务中是怎么作权限这块的？

1. 访问权限建议在服务网关处加以控制。
2. 资源权限建议抽象出一个单独的中间件加以控制。

微服务下有不一样的存储介质，对于跨数据库的分页查询有什么好的办法吗？

使用微服务架构能够作到：

1. 一个服务使用一个数据库（单库）
2. 一个服务使用多个数据库（多库）

对于“多库”而言，可在服务内部聚合数据，也可以使用数据库中间件来解决此问题。

SOA 与 MSA（微服务架构）区别在于系统一体化与服务组件分散化（“微化”）的区别。服务组件微化可让关注点进一步缩小范围，服务之间的规范或者实现的关联性进一步下降(https://my.oschina.net/waylau/blog/617857)。但同时引入的一些问题：

• 服务治理；
• 服务的版本更新；
• 服务之间的权限是如何来作控制的；
• 服务如何来划分颗粒度。

请教下，贵公司在实践过程当中，有无遇到过上述问题，是如何解决的？

您说的很是好，这些问题可能都是每一位微服务实践者所要面对的问题，考验咱们的是，如何选择合理的技术来解决此类问题。好比，服务治理可经过 Kubernetes、Mesos、Docker Swarm 等技术来实现，服务版本可经过 ZooKeeper、Etcd、Consul 等技术来控制，服务权限可自行实现权限中间件来解决，服务颗粒度划分考验咱们的是对业务的深度理解（这才是最为关键的）。总之，有具体技术能解决的可能都不是问题，多是问题的每每是咱们对自身业务的理解与把控能力。

1. 微服务对网络、数据库链接、缓存服务器等资源的影响；2. 微服务是否须要多版本服务共存？

1. 微服务对网络、数据库、缓存方面较传统架构而言，没有太高的要求，但对运维方面要求较高。
2. 微服务须要考虑服务多版本问题，尤为是服务升级时，须要作到平滑，对总体系统没有任何影响。

针对微服务的全局 ID 生成策略。不知道黄老师有没有什么好的建议？

1. 看了不少的分布式 ID 生成策略。提到不少 ID 趋势递增的策略，这个有什么用？
2. 为何要让 ID 具体有顺序功能？如何保证顺序？

不知道黄老师在实际项目中用了什么策略，但愿能分享一下。

实际上 ID 生成策略并不是是微服务架构所涵盖的范畴。我认为比较好的 ID 生成策略须要结合您所面临的实际需求，通常应用场景下，可经过 Redis 来生成并管理 ID，它具有较高的并发能力，且能确保分布式一致性。

有一个关于测试的问题想请教。是否是微服务更偏重敏捷模式呢？对于测试而言更容易开展工做？自动化测试覆盖率更高？

1. 我认为微服务与敏捷没有必然的关系，微服务讲究的是将“化整为零”，敏捷倡导的是“小步快跑”，但二者能够有效地结合起来加以应用。
2. 较传统架构而言，微服务的测试复杂度和覆盖面将更为普遍，不只须要对每一个服务进行测试，并且须要对总体应用加以验证。所以，咱们须要使用自动化测试技术来提升测试效率。

微服务是否就必定是进程级别的？在同一个进程内实现微服务可行吗？若是一个服务就一个进程，这样是否是会耗费大量系统资源？

1. 微服务讲究的是服务能够独立开发与部署，若是在进程内进行微服务，将带来很高的复杂度，就像当年的 OSGi 那样，理念很是好，但实践起来却困难重重。
2. 一个服务一个进程，这样让服务的隔离性更加完全，配合 Docker 容器技术，能够更加高效低利用服务器硬件与网络资源。

微服务目前有什么成熟的一整套开源方案吗？包括测试、版本控制，发布流程，代码错误回滚？

业界也有其余优秀的微服务开源方案，例如 Java 领域的 Netflix 与 Spring Cloud。固然，我更但愿本书所提到的开源方案，能够被更多人接受并应用。

微服务怎么解决调用链过长致使的调试或异常追踪过难的问题呢？

调用链追踪是微服务落地的一个挑战，咱们通常经过追踪平台来解决，推荐使用开源的 Zipkin。

微服务通常是 JSON 格式调用，与其余调用方式有什么区别么？

我认为 JSON 格式只是 REST API 返回值的一种，微服务并不是局限于 REST API 通讯。

楼主推荐使用 Spring Cloud 构建微服务吗？

Spring Cloud 对微服务架构提供了很好的技术封装，建议对其充分了解的状况下使用。

微服务都是经过 HTTP 方式对外提供？

微服务对外的接口不必定局限于 HTTP 或 HTTPS，也能够是 TCP，须要根据具体状况而定。

使用 REST 通讯其实挺麻烦的，还须要封装一层调用方法，不知道有没有相似的问题？

REST API 是一个种轻量级通讯方式，也有助于跨平台调用，咱们的作法每每是提供一个客户端 SDK，目前已有大量的技术来快速实现 REST SDK，好比 Spring RestTemplate，或 Retrofit。

8、微服务与容器的结合会碰撞出怎样的问题？

目前很火的容器技术和微服务如何结合？

因为微服务架构是能够作到服务的异构性的，也就是说，咱们可根据实际状况，选择最适合的开发语言来实现服务。容器技术具有隔离性，可将异构开发语言的服务进行统一封装，并有助于自动化部署，以及持续交付。

Docker 容器技术的出现，为微服务提供了更便利的条件，好比更小的部署单元，每一个服务能够经过相似 Node.js 或 Spring Boot 的技术跑在本身的进程中。可能在几十台计算机中运行成千上万个 Docker 容器，这么多 Docker 容器怎么来有效管理？出错了如何排查呢？

实际上您提到的是服务治理问题，目前有大量的技术能够作到，好比：Google Kubernetes、Apache Mesos、Docker Swarm 等。

据说使用 Docker 运行 Java 一点优点都没有，微服务架构大量启动 Docker 集群，内存利用率很低，虽然 Java 运行效率很高。您怎么看？

Java 应用经 Docker 化后，最明显的问题是 Docker 镜像体积较大，启动 Docker 容器所占用的系统资源较高。建议根据实际业务场景，选择最为合适的开发语言实现对应的微服务，而并不是局限于 Java 应用之上。

若是不使用 Docker，会给微服务带来哪些不便？

若是没有 Docker 这类容器技术，可能会下降微服务的部署与交付能力。

Spring Boot 与 Docker 整合， 在大数据使用方面多很少？

Spring Boot 与 Docker 整合，在许多领域都有应用，固然不排除大数据方面。

有关微服务的相关问答内容至此结束。做为开发者，多尝试各类技术对于开阔本身的眼界和思路是十分有益的。并且遇到问题也能够经过互联网寻求解决的办法，像开源中国的技术问答区上面就有不少活跃的技术大牛，欢迎你们在上面踊跃提问和回答。