微服务是什么

成功的路都是辛苦的，现在难受就对了，因为你在进步，毕竟舒服是留给死人的，活着是不是就该累呀。

---

马丁富勒——微服务的提出者、业内的大牛马丁·福勒

微服务是什么，我们最应该听听的是不是微服务的提出者、业内的大牛马丁·福勒的说法呢？他的个人博客网站是这么描述的 “a definition of this new architectural term” （重新定义并开启了一套软件架构）

The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.

大意是说就目前而言，对于微服务业界并没有一个统一的、标准的定义（Whie there is no precise definition of this architectural style）
那么什么是微服务，不能没有定义吧，我们看看马丁·富勒对它的定义

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

但是通常而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡单一应用程序划分为一组小的服务，每个服务运行在其独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通知是基于HTTP的RESTful API）。每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

马丁富勒的博客解读

拆分——为什么微服务没有一个统一的划分规则

其中有个很重要的原因就是拆分维度，是按照技术拆、按领域模型拆、按业务流程拆，仁者见仁、智者见智，没有达成统一，所以目前我们取最折中的基本上都是按业务。比方说淘宝的电商购物网站，最简单的买家业务与和卖家业务是不一样的吧。

各自独立——它提倡单一应用程序划分为一组小的服务

大家都知道在软件开始以前，第一个阶段是单机版，俗称All in One，就是在eclipse里只有一个工程，
Tmall
com.jigou.service
商品/交易/订单/积分。。。

随着互联网的崛起，并发量越来越大，“天下大势合久必分分久必合”，也就从单机版变成了分布式
专业的事情交给专业的人做，尽量降低耦合度。什么意思呢？就好比一屋子人在合租，一个人感冒了是不是会交叉感染，我们最终分灶吃饭，各做各的，我们会把上面放在一块的All In One变成4个模块，每一个模块大家按照业务来拆分，就可以把它看成一个微服务，比方说我们做过的一个短信模块，登录、下订单、动账金额需要发短信，这么多模块都需要发短信，干脆将这个公共的模块提出来，专业的人做专业的事情，发短信就只发短信，这样发短信就变成一个小模块，用maven形成一个model，只做一件事形成一个微服务，别人发短信不用做一套，专门来调我。

左边好比我们的群租房，多人挤在一块，上下铺；右边每个人都有自己的小单间，从住宿的角度，哪一种更舒服不言自明吧。

拥有自己独立的数据库

左边图，人是各个产品的角色开发、运维、产品经理一堆的协作的小伙伴，中间的长方体是消息模块、订单模块、物流模块等等，大家业务层一个整体塞在一块，挤在一块，最下面是数据存储，商品表、订单表、物流表三张不同的表也在单一的数据库里，这时候耦合度很高，任何一个出了问题大家都得陪着。

右边图，干脆我们专业的人做专业的事，我们可以通过外部的配置（人下面的小纸条，比如springcloud config分布式配置中心），这个时候假如运维人员需要切库，就可以在外部修改信息，自动的进行刷新和变更，这张图还更好的告诉大家微服务-基于应用的数据库可以独立出来，各自连各自的数据库，也可以多个微服务连接同一个库，将耦合度降低到最小呀。

技术性的语言

微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务只做一件事，从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自动单独启动或销毁，拥有自己独立的数据库。

建议

不要只会用，不要满足于在eclipse/idea中点几下，一个点出现一个方法调用下，那个时候只不过是一个调用师，或者API工程师，根本不是我们需要的软件工程师，恋物不练功到老一场空，希望大家读下马丁富勒的原文，加深下对微服务的理解。