阿里前P8高级架构师讲述微服务架构

什么是微服务？

微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发。当前被越来越多的开发者推崇，很多互联网行业巨头、开源社区等都开始了微服务的讨论和实践。Hailo有160个不同服务构成，NetFlix有大约600个服务。国内方面，阿里巴巴、腾讯、360、京东、58同城等很多互联网公司都进行了微服务化实践。当前微服务的开发框架也非常多，比较著名的有Dubbo、SpringCloud、thrift 、grpc等。

定义总是晦涩些，如果将微服务拆开理解就简单许多：

• 微：它基于单一责任的“微小”功能模块，这些微小模块从前端WEB UI，到控制层、逻辑层、数据库访问以及数据库都可以是完全独立的一整套。——独立部署、互相隔离
• 服务：业务被拆分成多个“微小”服务模块，这些模块之间通过使用轻量的通讯协议和简单的数据结构沟通（通常可采用http+json），因此，每个微小模块需要消费外部其它微小模块暴露的服务，同时还需对外提供服务。——我为人人，人人为我

微服务落地存在的问题

虽然微服务现在如火如荼，但对其实践其实仍处于探索阶段。很多中小型互联网公司，鉴于经验、技术实力等问题，微服务落地比较困难。如著名架构师Chris Richardson所言，目前存在的主要困难有如下几方面：

1. 单体应用拆分为分布式系统后，进程间的通讯机制和故障处理措施变的更加复杂。
2. 系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出。
3. 微服务数量众多，其测试、部署、监控等都变的更加困难。

随着RPC框架的成熟，第一个问题已经逐渐得到解决。例如dubbo可以支持多种通讯协议，springcloud可以非常好的支持restful调用。对于第三个问题，随着docker、devops技术的发展以及各公有云paas平台自动化运维工具的推出，微服务的测试、部署与运维会变得越来越容易。

而对于第二个问题，现在还没有通用方案很好的解决微服务产生的事务问题。分布式事务已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。 为此，本文将深入和大家探讨微服务架构下，分布式事务的各种解决方案，并重点为大家解读阿里巴巴提出的分布式事务解决方案----GTS。该方案中提到的GTS是全新一代解决微服务问题的分布式事务互联网中间件。

为什么需要微服务？

在讨论为什么的问题之前，我们先回顾一下服务化架构的演进。

服务化架构演进图

从图中我们可知，随着互联网的发展，网站应用的规模不断扩大，微服务之前的架构面临着多方面的挑战：

• 代码重复率高，模块过度依赖。
• 共享困难，公共类库维护成本高。
• 需求变更困难，新业务快速交付难。
• 可扩展性差，功能模块按需扩展难。
• 运维成本高，测试、部署成本高。

简单总结各个演进架构（包括微服务）的优缺点，如下表格所示：

其实，在软件开发里，不同的架构并没有哪个更好的说法。对于架构的选型，只有合适与不合适之说。比如，简单的小型应用开发，就可直接使用单体架构设计，直接打包，方便部署，容易测试，响应迅速。所以，我们应该结合对技术和业务的理解，选择更符合我们的目标架构。

从上文我们知道微服务能给我们带来众多好处

尤其对于较大规模的应用开发在业务大规模爬升时，微服务方法体现出许多优势，包括更快的上线时间、灵活性、弹性、一致性以及相对更低的成本。

1. 开发效率更高
2. 沟通成本更低
3. 响应速度更快
4. 迭代周期更短

那如何应用微服务呢？下面从五个方面来谈：

单体架构拆分

下面这张老外的抽象“拆分图”，从三个维度概括了一个系统的扩展过程：

• x轴，水平复制，即在负载均衡服务器后增加多个WEB服务器，实现分布式部署；
• z轴扩展，是对数据库的扩展，即分库分表（分库是将关系紧密的表放在一台数据库服务器上，分表是因为一张表的数据太多，需要将一张表的数据通过hash放在不同的数据库服务器上）；
• y轴扩展，是功能分解，将不同职能的模块分成不同的服务。从y轴这个方向扩展，能将巨型应用分解为一组不同的服务。不同服务使用不同的数据，与外部交互通过消息或API，每个服务设计需要把握“微”的度，不宜在基础功能上做过多堆叠，否则每个微服务组件可能又变成大的单体应用。

服务治理

服务治理依赖底层的技术支持，需要做好很多必要的技术知识储备。

• 搭建微服务总线和通讯机制

这个问题涉及到几个方面，如服务注册、服务发现、服务调用。阿里开源的Dubbo框架就是一种微服务框架，它借助Zookeeper等多种注册中心实现对Provider服务的注册，并且提供服务发现功能。Dubbo支持Hessian、WebService、Thrift等方式的RPC远程服务调用，此外当当的Dubbox（由Dubbo扩展新功能而成，即DubboeXtensions）还支持RESTAPI的服务调用方式。事实上更地道的微服务架构会采用基于异步通信的调用。在异步通信中，各服务间彼此依赖，但不会因相互等待结果而导致响应速度缓慢。因此，如果一项服务发生故障，其不会影响到其它服务，瓶颈与单点故障问题也将不复存在。

• 负载均衡

Dubbo提供的ConfigServer的原理，就可知道如何保证微服务系统的负载均衡和整体的可靠性问题了。Dubbo的配置中心和每个Server/Client之间会作一个实时的心跳检测，收集并更新每个Server提供的服务的信息和每个Client的信息。每个Server启动时，主动与ConfigServer建立连接，并将自己的IP，提供的服务名称，端口等信息直接发送给ConfigServer，ConfigServer会更新服务列表。Client在使用服务的时候根据服务名称去ConfigServer中获取服务提供者信息，后面就可以直接调用服务了。当有多个服务提供者的时候，Client根据一定的规则来进行负载均衡，如轮询、随机、按权重等。一旦Client使用的服务它对应的服务提供者有变化，ConfigServer就会把最新的服务提供者列表推送给Client，Client重新建立连接。

自动化测试

微服务一个明显的表象就是随着业务规模的扩大，服务将会增多、增强。传统的测试模式就会遇到瓶颈，为了保证高效的迭代，尽量做到更多的环节实现自动化。

自动运维

微服务拆分之后，每个服务都可以独立打包、发布、部署、启停、扩容和升级，核心服务独立集群部署，进而言之应该是随时随地可以升级。尤其当互联网发展到今天，业务要保持对市场变化的一个高效响应，自动化运维就是提升交付速度的一个重要环节。

监控

包括硬件环境、服务状态、系统健康度、接口调用情况、异常的实时告警以及潜在问题的事先预警等等。监控在实施微服务过程中会重要到什么程度呢？一句话：没准备好监控，就不要搞微服务。

微服务不是银弹？

软件领域没有银弹，微服务带来了很多收益，同时它也引入了很多问题，总结以下几点供将准备搞微服务架构的同学们思考。

• 时延问题，服务之间远程通信增加的性能损耗。
• 事务一致性，有逻辑关联的多个数据库操作被分布到多个独立的服务中，在分布式环境下引起的事务一致性问题。
• 问题定位，分布式环境下，问题定位和日志检索。
• 测试运维难度增大，跨服务的测试将更复杂，运维工作更具挑战。