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

What：什么是微服务？

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

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

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

微：它基于单一责任的“微小”功能模块，这些微小模块从前端 WEB UI，到控制层、逻辑层、数据库访问以及数据库都可以是完全独立的一整套。——独立部署、互相隔离

服务：业务被拆分成多个“微小”服务模块，这些模块之间通过使用轻量的通讯协议和简单的数据结构沟通（通常可采用 http+json），因此，每个微小模块需要消费外部其它微小模块暴露的服务，同时还需对外提供服务。——我为人人，人人为我

Why：为什么需要微服务

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



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

代码重复率高，模块过度依赖。

共享困难，公共类库维护成本高。

需求变更困难，新业务快速交付难。

可扩展性差，功能模块按需扩展难。

运维成本高，测试、部署成本高。

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



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

How：怎么用微服务

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

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

单体架构拆分

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

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

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

自动化测试

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

自动运维

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

监控

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

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

时延问题，服务之间远程通信增加的性能损耗。

事务一致性，有逻辑关联的多个数据库操作被分布到多个独立的服务中，在分布式环境下引起的事务一致性问题。

问题定位，分布式环境下，问题定位和日志检索。

测试运维难度增大，跨服务的测试将更复杂，运维工作更具挑战。