微服务指南走北（五）：什么样的服务才可以说是微服务？

时间：2017-04-23 20:14:30 阅读：233 评论：0 收藏：0 [点我收藏+]

最近有朋友提出了问题：“是不是拥有了服务发现就是微服务了？”，对于这个问题，很难回答，毕竟微服务的定义在每个人心里都是不一样的，就像“互联网思维”一样，我们说得清“互联网”，却总也说不清楚什么是“互联网思维”（在这个思想开放的互联网时代，你我都是哈姆雷特，但是也是交流沟通便利性的时代）。今天总结这篇文章呢，来说说我对微服务的理解，以及再来探讨下微服务的定义。

首先，微服务是什么？

其实回头看看我之前写的《微服务指南走北》系列的第一篇《微服务指南走北（一）：微服务是什么》中描述的：微服务是基于Restful风格的，基于资源及资源操作一组API的集合，可以实现模块儿或者说是特定的业务范围内的一个完全独立、细粒度、自包含的一个服务。每个微服务提供一组API，供其他微服务或者应用客户端所用。

其中，包含如下几个要点：
1. 基于资源
2. 模块儿化或者业务独立

微服务的“微”究竟是什么意思

几个误区：

模块儿化：不得不说，微服务确实可以天然实现模块儿化，将不同的模块划分为不同的服务。但是这里存在一个误区，就是很多人想要借用微服务来实现模块化，从而去分解庞大的系统；不能说这样做有什么问题，但是从解决问题的角度来说，微服务的主旨并不是为了实现模块化，并且只要架构合理，单体应用也可以做好模块化。同理，架构模式不合理，必然导致微服务管理上的灾难（以后单独写文章来聊聊这个问题）。
服务微小化：微服务并不是说要将服务拆分成多个微小的服务，举个例子，假设java单体应用本来有2个功能，一个是账户管理，一个是订单管理。运行起来的WebServer一共占用内存是50M，假设其中20M是WebServer自身占用的内存，那么分为两个微服务以后，就需要单独启动两个WebServer，那么就需要多占用20M的内存（当然这里拿WebServer来讲，并不是很合适，毕竟jvm中自身有优化），如果进一步结合docker来使用，那么在docker中，还需要增加额外的内存，关于这个问题，就不详解了，想了解的朋友可以参考如下文章Analyzing java memory usage in a Docker container。内存还仅仅是一方面，由于服务拆分而导致的HA、维护等成本的开销也会增加很多。

我的理解

我认为微服务的“微”主要体现在业务的分离上，也许一个服务会占用较大内存，但是业务相对独立，每个服务负责相应的业务；就像我们常见的公司的组织架构一样，不同的部门来完成不同的任务，不同部门之间相互配合又相互独立。

微服务的优点

我们先来回顾下之前我所总结的微服务的优点（摘自《微服务指南走北（一）：微服务是什么》）：
1. 可以解决复杂性的问题，在功能不变的情况下，分解为多个相互协作的微服务，通过rest API定义边界，这样极大易于开发、理解和维护。

微服务架构是的每个服务可以由专门的开发团队或者个人开发者进行开发，开发者可以自由选择技术，不必受制于规定的技术和框架，只要API服务协议好交互方式即可（如restful）。这样即使重新技术过时的微服务模块儿或者重写以前的代码，也不是很困难。
微服务架构模式使得每个微服务独立部署，且每个服务独立扩展，开发者不再需要协调其它服务部署对本服务的影响。微服务架构模式使得持续化部署成为可能。

这里我再补充几个优点：
4. 微服务可以结合docker相关服务，易于实现HA（比如kubernetes + docker + 微服务），使得可以服务不会受到单点故障的影响。

我认为的微服务应该具备的特点

以下是我实际应用微服务架构需要保证的特点：

所有的服务都尽量保证无状态或者有状态的可以做状态转移（如session等数据，可以转移到redis集群中）
业务的相对分离
使用API网关（尽量不要将微服务的各个服务暴露出去，以免造成安全问题）
服务间采用统一的通信模式（restful、Thrift等）
能够脱离开发语言，即不受制于特定的开发语言
微服务中的各个服务尽量不要有强依赖（即不会因为某个服务的停止，而导致整个服务或者其他服务不可用）
具有易于实现HA的特质，即不存在单点故障，同时运行多个实例提供服务并实现了负载均衡

什么样的服务才可以说是微服务？

对于这个问题，到这里，我也无法做出定论，但是比较确定的是微服务是在特定情境下使用的架构思想，既然是思想，就如开篇所说的，大家都是哈姆雷特，我也只能对我自己的理解进行描述，无法对你心里的思想进行固化，不过如果你感觉比较模糊，可以借鉴我再实际应用中总结的微服务需要保证的特点（即上一章描述的）。