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

时间 2019-11-10

标签微服指南什么样服务能够繁體版

原文原文链接

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

首先，微服务是什么？

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

其中，包含以下几个要点：docker

基于资源安全
模块儿化或者业务独立restful

微服务的“微”到底是什么意思

几个误区：

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

个人理解

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

微服务的优势

咱们先来回顾下以前我所总结的微服务的优势（摘自《微服务指南走北（一）：微服务是什么》）：框架

能够解决复杂性的问题，在功能不变的状况下，分解为多个相互协做的微服务，经过rest API定义边界，这样极大易于开发、理解和维护。jvm
微服务架构是的每一个服务能够由专门的开发团队或者我的开发者进行开发，开发者能够自由选择技术，没必要受制于规定的技术和框架，只要API服务协议好交互方式便可（如restful）。这样即便从新技术过期的微服务模块儿或者重写之前的代码，也不是很困难。
微服务架构模式使得每一个微服务独立部署，且每一个服务独立扩展，开发者再也不须要协调其它服务部署对本服务的影响。微服务架构模式使得持续化部署成为可能。

这里我再补充几个优势：

微服务能够结合docker相关服务，易于实现HA（好比kubernetes + docker + 微服务），使得能够服务不会受到单点故障的影响。

我认为的微服务应该具有的特色

如下是我实际应用微服务架构须要保证的特色：

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

什么样的服务才能够说是微服务？

对于这个问题，到这里，我也没法作出定论，可是比较肯定的是微服务是在特定情境下使用的架构思想，既然是思想，就如开篇所说的，你们都是哈姆雷特，我也只能对我本身的理解进行描述，没法对你内心的思想进行固化，不过若是你感受比较模糊，能够借鉴我再实际应用中总结的微服务须要保证的特色（即上一章描述的）。