微服务架构之思维三部曲：WhatWhyHow

Posted 2021-04-14 ServiceMesh中文网

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了微服务架构之思维三部曲：WhatWhyHow相关的知识，希望对你有一定的参考价值。

What：什么是微服务？

某百科对微服务架构的定义和阐述：

微服务可以在“自己的程序”中运行，并通过“轻量级设备与 HTTP 型 API 进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。

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

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

Why：为什么需要微服务

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

微服务架构之思维三部曲：What、Why、How

图1 服务化架构演进图

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

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

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

微服务架构之思维三部曲：What、Why、How

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

How：怎么用微服务

从上文我们知道微服务能给我们带来众多好处，尤其对于较大规模的应用开发在业务大规模爬升时，微服务的架构的优势更加凸显：1、开发效率更高。2、沟通成本更低。3、响应速度更快。4、迭代周期更短。

那如何应用微服务呢？需要做哪些准备工作？下面从五个方面来谈：

1、单体架构拆分

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

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

2、服务治理

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

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

这个问题涉及到几个方面，如服务注册、服务发现、服务调用。阿里开源的 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 重新建立连接。

3、自动化测试

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

4、自动运维

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

5、监控

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

微服务不是银弹？

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

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