组件化、模块化、集中式、分布式、服务化、面向服务的架构、微服务架构

 最近最火的词是什么？那大概就是微服务（Microservice）了。最近也火的一踏糊涂的Docker、AppOps也都是围绕着微服务领域的。在微服务领域还有很多相关名词。这些名词有一个共同的特点那就是晦涩难懂。他们就像中国古代的道、气、八卦等词一样，一解释就懂，一问就不知，一讨论就打架。

本文主要来介绍几个和微服务相关的概念。这些概念的都是博主在浏览了大量资料之后总结出的个人见解，如有偏颇，请指正，共勉之。

组件化与模块化

首先来谈两个前端和移动端比较常见的词：组件化和模块化（后面我会说到为什么要先介绍组件化和模块化）。

首先，可以肯定的是，组件化和模块化的中心思想都是分而治之。目的都是将一个庞大的系统拆分成多个组件或者说是模块。

组件化

首先来看维基百科中关于组件化（Component-based software engineering）的介绍：

Component-based software engineering (CBSE), also known as component-based development (CBD), is a branch of software engineering that emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system. It is a reuse-based approach to defining, implementing and composing loosely coupled independent components into systems. This practice aims to bring about an equally wide-ranging degree of benefits in both the short-term and the long-term for the software itself and for organizations that sponsor such software.

大概意思就是：组件化就是基于可重用的目的，将一个大的软件系统按照分离关注点的形式，拆分成多个独立的组件，主要目的就是减少耦合。

• 一个独立的组件可以是一个软件包、web服务、web资源或者是封装了一些函数的模块。这样，独立出来的组件可以单独维护和升级而不会影响到其他的组件。

模块化

维基百科中对模块化Modular Programming的定义如下：

Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.

With modular programming, concerns are separated such that modules perform logically discrete functions, interacting through well-defined interfaces.

模块化的目的在于将一个程序按照其功能做拆分，分成相互独立的模块，以便于每个模块只包含与其功能相关的内容，模块之间通过接口调用。将一个大的系统模块化之后，每个模块都可以被高度复用。

模块化和组件化的区别

从上面的定义中可以看出，组件化和模块化的意思差不多，主要思想都是分而治之。只是一个把拆分之后的每个片段叫做组件、另一个把拆分之后的片段叫做模块。那么这两种拆分在拆分方式上是不是有什么不同的？

关于组件化和模块化的区别，我在网上看了好多资料，也没有人能给出准确的回答。其实没有准确回答的原因也比较明显，那就是大多数时候我们真的不需要严格的区分这两个名字。我们要学习的是其中的解耦和分治的思想和目的。

从另外一个角度来讲，如果真的要区分一下组件化和模块化的话，那么可以认为这两种分而治之的目的稍有区别：

模块化的目的是为了重用，模块化后可以方便重复使用和插拨到不同的平台，不同的业务逻辑过程中。

组件化的目的是为了解耦，把系统拆分成多个组件，分离组件边界和责任，便于独立升级和维护。

集中式与分布式

要谈微服务，那么必须建立在分布式的基础上，对于一个集中式系统也无需谈微服务。在我的另外一篇文章微观SOA：服务设计原则及其实践方式（上篇））

微服务架构

微服务架构(MicroService)是一种服务化架构风格，通过将功能分散到各个离散的服务中以实现对解决方案的解耦。微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化（这也是我们为什么要先介绍组件化和服务化的原因）。微服务的诞生并非偶然。它是互联网高速发展，敏捷、精益、持续交付方法论的深入人心，虚拟化技术与DevOps文化的快速发展以及传统单块架构无法适应快速变化等多重因素的推动下所诞生的产物。

微服务的流行，Martin功不可没，先看看他是如何定义微服务的：

The microservice architectural style is an approach to developing a single application asa 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.

总结起来大概以下四点：

• 一些列的独立的服务共同组成系统
• 单独部署，跑在自己的进程里
• 每个服务为独立的业务开发
• 分布式的管理

Martin自己也说了，每个人对微服务都可以有自己的理解，不过大概的标准还是有一些的。

• 分布式服务组成的系统
• 按照业务而不是技术来划分组织
• 做有生命的产品而不是项目
• Smart endpoints and dumb pipes（我的理解是强服务个体和弱通信）
• 自动化运维（DevOps）
• 容错
• 快速演化

SOA和微服务

看了SOA和微服务，很多人会认为这不就是一回事儿么。其实SOA和微服务就是差不多的。

如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线。微服务把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的ESB，服务间轻通信，是比SOA更彻底的拆分。（微服务（Microservice）那点事）

关于微服务这里只是做一个简单的介绍，要想真正的了解微服务还有很多路要走，比如康威定律（我后面会专门写一篇文章介绍康威定律）、服务间通信、服务的注册与发现、服务治理与服务编排等。。。

总结

本文主要介绍了组件化、模块化、集中式、分布式、服务化、面向服务的架构、微服务架构等概念。但是，正所谓实践出真知。还是要在日常工作中实际运用才能真正的掌握。