微服务九大特性（经由服务组件化）

书接上文。

前面一篇文章《微服务漫谈之什么是微服务》中，咱们聊过了微服务是什么这个话题。一句话简单总结就是：『微服务』这个名词所代表的是一套架构风格（Architectural Style），而不是研究什么样的服务是微服务。

不过Martin自己也说了，他不能说对微服务架构风格有一个正式的定义。让我们来看看百度百科上对定义的定义：

定义：英文是Definition，原指对事物做出的明确价值描述。现代定义则是：对于一种事物的本质特征或一个概念的内涵和外延的确切而简要的说明；或是透过列出一个事件或者一个物件的基本属性来描述或规范一个词或一个概念的意义。被定义的事件或者物件叫做被定义项。一般地，能清楚的规定某一名称或术语的概念叫做该名称或术语的定义。

从上面对定义的定义来看，当无法确切的说明被定义项的时候，那么干脆咱们可以用被定义项的基本属性来描述。

因此Martin&James给出的微服务架构风格的九大特性，也算是对微服务架构风格的另一种定义方式了。

那我们来看看微服务的九大特性都有哪些。

经由服务组件化

---

组件似乎是软件世界里面的一个最高频的词汇，是谁创造出了这个概念已经无从考究，但是几乎所有语言中都有这个词汇的身影。C++中有组件、Delphi中有组件、Java中有组件、JavaScript中有组件，到处都是组件。

组件很好理解。

我儿子最喜欢搭的乐高积木就是组件化的产品。乐高有若干种小颗粒，这些小颗粒有不同的几个种类，很多个各种小颗粒组合成各种形状，拼装到一起可以组合成任何乐高式的物品。拼装物品时，同类的组件（小颗粒）间可以互相替换。拼装后的物品可以是小人、房屋，也可以是一把刀、一把枪。拼装好乐高式的物品之后，我家小孩就在不停地场景下应用：用搭成小人、房屋做个游戏，或者搭成小人、拿一把刀给爸爸来一下。

组件也很难定义。

可以替换的东西就都叫组件了？那我在搭建乐高时，弄一个小人放到农场里，同时它也可以放到警察局里，这个小人是不是一个组件？你说那叫应用？为啥不能叫组件？然后你就开始头疼、开始各种不适以及纠结了。

Martin也意识到了这个问题，因此在描述微服务时给出了三个定义：组件、服务以及Library。我们先列出定义：

1. 组件（Component）：是可以独立替换和升级的单元。

2. 库（Libraries）：链接到程序中，并以内存方式进行功能调用的组件。

3. 服务（services）：进程外组件，服务之间通过某种轻量级的机制进行调用。

微服务中最关键的定义就这三个了。

我认为这是Martin在描述微服务的时候，做得最成功的一点。他从被调用方式出发，把微服务的关键概念和组件进行了进一步细致的解释，同时又进行了隔离。

理解一下子变得简单起来了，在任何具体的架构实例下都可以一句话解释清楚：以内存方式调用的都是库，独立运行对外提供服务的都是服务。

他大舅、他二舅都是他舅，高桌子、低板凳都是木头！就如这陕西方言一样让人印象深刻。

那么经由服务组件化，咱们也可以很简单理解了：

微服务架构风格下，任何应用首先要拆解成一个一个的服务组件，这些服务之间通过轻量级的通信机制进行通讯，可以各自独立的开发、部署以及维护。

经由服务组件化的好处有下面几点：

1. 可以独立开发、部署以及运维

2. 服务间耦合降低（这是相对于单体应用来讲的，单体应用各模块/组件之间的调用全部是in memory function call，相对而言轻量级接口的耦合当然耦合更低）

当然使用服务也有缺点，列举如下：

1. 性能降低，简单来说就是慢。

   远程调用毫无疑问更加昂贵，网络延时也带来了性能方面的损耗。

2. 更难使用：简单来说就是烦。

   因为远程调用更加昂贵，所以API的粒度必然有时会朝更粗粒度考虑，进而导致更难使用

3. 更难变更：简单来说就是步子走大一点就容易扯着蛋。

   当跨越了进程的边界时，如果要变更服务之间的职责会更加困难。

看着问题也不少，那么咋整呢？

别急，微服务九大特性中的另外一些特性，以及别的一些手段（诸如DDD啊，契约驱动设计/开发/测试之类的），可以或多或少的缓解一些这类问题。这些因为和当前内容无关，放到后面再给大家介绍吧。

今天先到这里，敬请期待下篇《微服务九大特性之二  ——  产品而不是项目》