微服务是目前互联网公司最常用的架构，与传统单体架构相比，微服务架构更加适应互联网快速、灵活的特点，接下来的系列文章我会逐一介绍微服务架构的核心知识点。
第一篇我们先来了解什么是微服务。
微服务的特点
微服务最经典的定义是Martinfowler老爷子在2014年的一篇文章中介绍的，原文如下：
the microservice architectural style 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.
总结起来有六点：
- 一组小的服务
- 运行在独立的进程中
- 使用轻量级通信协议
- 基于业务能力构建
- 独立部署
- 无集中式管理
为了能更好的理解这些特点，我们需要将单体架构拿出来与微服务架构进行比较。
假设有一个用户信息管理系统，包含了注册、登录、信息维护、授权四个核心功能。使用单体架构时，所有的功能会被放在一起，而使用微服务架构时，它们可以被拆分成四个独立的服务。
下面我结合这张图来一个一个说明微服务架构的六大特点。
一组小的服务
由于被拆分成四个独立的服务，所以相对单体架构而言，微服务架构下的每个服务都更"小"了。
但要注意的是，这里的"小"是相对的，没有统一标准，例如代码少于N行，功能点少于M个。
在划分微服务时，我们需要避免一味追求小而将微服务划分得过细，因为这样会提高系统维护成本。
运行在独立的进程中
例如JAVA开发的单体架构系统，所有业务功能包含在一个WAR包里，部署在相同的容器中，业务功能之间共享进程。
而微服务之间是独立的，他们可以部署在一个容器里，也可以分开部署，最重要的是它们之间不会共享进程。
这样做有利于灵活的分配资源，各个服务之间也不会互相干扰。
使用轻量级通信协议
在单体架构下，不同系统间的交互常常会使用重量级的协议，例如SOAP。
微服务由于拆分得更细，服务间调用更加频繁，因此更倾向使用轻量级的协议，例如Http、RPC。
基于业务能力构建
划分微服务的原则不是看它有多小，而是看单一的业务能力是否被划分到一个服务中。
例如前面的用户信息管理系统，我们是按业务能力划分了四个微服务，而不是按功能划分出前端服务、接入服务、逻辑服务、数据库服务。
独立部署
在单体服务中，即使是一个小功能的改动，也需要重新发布整个系统。而在微服务架构下，只需要单独部署有改动服务。
独立部署的特性，使得微服务架构系统能够以更快的速度迭代，而这也是互联网软件非常重要的一个特性。
无集中式管理
单体服务架构由于集中管理，所以使用的技术栈往往也是相同的。微服务架构则可以根据服务特性选择不同的技术栈，例如注册服务用 MYSQL + REDIS，信息维护服务使用Oracle。
无集中式管理使得微服务架构系统的选择性更多，可以根据需求选择最优的技术方案。
总结
软件架构体系经历了单体 -> SOA -> 微服务 三个阶段，总体的趋势是划分越来越细，每个服务承担的职责越来越单一。
在前面介绍微服务的六个特点时，每个特点都能解决一些旧的问题，但是凡事都有两面性，解决旧问题的同时也可能带来一些新问题。
例如无集中式管理，增加了技术选择性的同时，也增加了研发成本，因为研发人员需要掌握更多的技术知识。
除了我举的例子之外，大家也可以思考一下，其它的特点都会带来哪些新的问题？欢迎留言与我讨论。
