背景
软件开发是一个不断发展的过程，从当初的面向过程为主到如今的面向对象的开发，软件开发者不断探索与实践更加符合时代发展要求的开发模式与架构思想，而这，也在极大程度上提高了软件开发的效率。
微服务是一种架构模式或者说是架构风格，而架构这个词语，相信有很多人都曾试图为它做出明确的定义，可是很难下，因为软件架构也在不断发展，内涵也在不断得到丰富。只是不变的是，我们需要通过软件架构，根据族组织、业务、技术等因素划分出不同的但可以相互协作的应用系统，使得设计出来的系统具有较高的伸缩性、可维护性以及可扩展性。
三层架构
曾经在与朋友讨论微服务的时候，朋友曾经说过三层架构是不是可以避免在某种程度上因架构设计带来的耦合度过大问题，我跟他说应该很难，因为三层就架构更多的关注是统一系统内的职责划分问题，而架构更多的是关注多套系统。这里的话，顺便提一下三层架构，大家对这种架构应该不会陌生，它主要包括表示层、业务逻辑层以及数据访问层，如下图所示
可以发现，三层架构方式使得各层的关注点更加清晰，但如果随着业务的扩大，三层架构只是延长了系统的生命周期，并不会对系统架构带来太大的改变。这就需要讨论单体系统带来的问题了。
单体系统
三层架构是一种经典的单体应用架构。单体系统有的特点就是，开发、测试、部署都比较简单，以前我所在的公司，因为性能问题，几乎需要花大力气重构系统的时候，却发现只需要再加几台服务器就可以很简单的解决这个问题了，这说明了系统的水平扩张也非常简单。但即便他这么简单，现在也已经不再推荐去做了。
单体系统意味着公司所有的业务逻辑都被整合进去了，想要一个新人快速上手几乎不太可能，同时老员工离职所带来的风险也是不可估量的。随着大量功能的集成，也对未来新需求的继续集成带来了很大的困难，牵一发而动全身，实在让人无可奈何。更重要的是，互联网的快速发展，要求我们要做到快速开发、快速集成、快速上线、快速迭代，而单体应用很难做到这点，因为很多团队都会要求对系统的核心功能进行回归。
所以从架构角度对系统进行拆分就成了一种必要，SOA也随之诞生，本文不会具体讨论SOA，只会简单说明一下SOA关于系统拆分的理念。SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。相对而言，SOA对系统拆分的力度似乎没有太“微”，但是和微服务思想几乎没有什么太大的区别了。
微服务与SOA
微服务与SOA的区别（由于很多场景下，SOA会使用到ESB，放在这里也方便与微服务做更好的比较，多说一句，ESB逐渐被P2P的虚拟总线所替代），如下图所示
通过上图，可以知道微服务与SOA最大的区别在于，SOA使用了ESB来集成基于不同协议的服务之间的交互工作，而微服务去除了中间的管道，以服务化方式进行交互和集成。
| SOA | 微服务架构 | |
| 关注点 | 关注可重用性的最大化，但服务粒度较大 | 彻底实现服务器的组件化，服务粒度较小，并关注“上下文边界” |
| 通信协议 | （通常会通过ESB调度）支持多种消息协议 | 使用轻量级协议，推荐使用REST full风格，如HTTP |
| 开发与交付 | 修改时，由于依赖较大，往往牵扯面很大，交付并不灵活 | 可以只是基于一套服务，交付快捷灵活 |
| 数据存储 | 可共享数据存储 | 每个微服务拥有独立的数据存储 |
| 部署 | 使用通用平台 | 可以不基于通用平台 |
| 服务治理 | 共同的治理和标准 | 服务微治理，实时生效 |
| 趋势 | DevOps、持续交付、容器，做的并不是很好 | DevOps、持续交付、容器在微服务方面的实践非常的丰富 |
总的来说，微服务是SOA的一个子集或者是升级版，它是SOA在互联网时代发展的必然进化结果，它有力的促进了企业级系统服务架构的实践。
微服务特性
前面有讲过，微服务是一种架构风格，一个大型应用系统有一个或多个微服务组成，系统中的各个微服务可被独立部署，各个微服务之间是松耦合的，每个微服务体现着单一职责原则。它主要有以下特性:
彻底的组件化
彻底的组件化有着极好的灵活性和可替换性，明确了单一职责，它可以在不影响或者极少影响其他业务组件的情况下进行快速迭代与快速交付，也实现了业务的高度内聚
技术的异构性
在微服务架构中可以根据不同的业务特征采用不同的技术方向，有针对性的解决具体的业务问题
独立存储与部署
每个微服务拥有自己的数据库，并部署在不同的平台上
围绕业务组建团队
不同于传统的IT团队，对技能以及职责的区分非常明确，在微服务里，提供以业务为核心，按业务能力组建团队，因此团队成员的技能是跨领域的一体化团队，通常团队不会太大。
写到最后
微服务确实有着无可比拟的优势，但是微服务也带来了很大的缺点：
加大分布式系统的复杂度：随着服务的拆分，原先基于进程内通讯的功能被迁移到了进程间通信或者网络通信，增加了不稳定性；也会存在服务版本的变化必须兼容其他服务的问题，从而导致接口版本过多，存有大量的重复代码
测试压力与运维成本：原先的一个系统被拆分出了很多套微服务，这些都需要增加测试与运维的投入
服务治理与监控也非常复杂，需要有人力的投入
所以，微服务的进行，需要根据现状在做决定，切不可为了拆分而拆分
