什么是微服务
从字面来解读微服务（micro service），了解微（micro）是什么意思，而服务（service）又是指什么。
微（micro）字面意思为小，意为要尽量控制单个服务的规模和成本。
服务（service）可以直接使用的一个或一组功能，用户不需要关心具体的实现，只需关心输入和输出。
从更为严谨的角度上来定义微服务：微服务是一种细粒度的分布式解决方案，这些细粒度的服务独立性强并且会协同工作。
微服务的由来
微服务的是詹姆斯·刘易斯（James Lewis）和马丁·富勒（Martin Fowler）提出的这一个概念，而且两人发表文章梳理了微服务架构设计的一些特征。
二人针对微服务给出的定义：“微服务的架构风格是将单个应用作为一组小型服务进行开发，每个服务都运行在自己的进程环境中，并通过轻量级机制（比如HTTP协议）进行通信。这些服务紧密围绕业务功能进行构建，可以通过自动化的方式进行部署。不同的服务之间可以采用不同的编程语言，并且管理方式尽可能不采用中央集中式”。
微服务是计算机技术进化的产物，包含很多具体技术，如服务的集成和编排早在SOA中就有提到了。计算机的技术都是延续的，微服务并非突然的完全创新，而是基于其他技术的微创新，在原有技术的基础上理解起来也容易。
微服务与微服务架构
微服务的概念和微服务架构是不一样的，微服务架构是一种具体的设计实现或者设计方案，而微服务是通过这种实现或方案最终完成的服务。
从技术角度来说，微服务框架与传统框架的区别就是对原来复杂的一体化框架进行拆分，将其拆分成众多独立的服务，并且为这些独立服务设计通信方式使之能够整合。
微服务则是微服务架构拆分出来的独立应用。微服务架构的核心是内部的“分”与外部的“合”，内部的分是指把原来复杂的功能拆分成很多独立的微服务，而从外部来讲，在使用的时候感觉不出和原来的明显差异。
所以，微服务架构的重点也是围绕如何“分”和如何“合”来进行的。
系统架构的演进
单体架构
单体架构是软件工程领域使用最早的架构，因为单体架构结构简单，所有功能都是可以看为一体的。
所谓单体架构就是指一个项目或者一个归档包（jar包或war包等）就完成了项目的所有功能。这种架构非常传统，很多的MVC（Model、View、Controller）分层设计都是为了解决单体应用架构过于复杂而演变出来的。
比如一个电商的订单、用户、收款等功能都在一个应用内实现，这就是单体架构。
但是随着应用的不断发展，单体架构缺点也是非常明显的，可以总结为以下几点：
● 复杂性高：整体项目工程量大，各个功能之间的界限比较模糊，逻辑不够清晰。随着应用的扩展，复杂性也越来越高。
● 知识转移难：软件开发行业的人员流动非常正常，但是要想完成一个单体应用的知识转移却非常难。文档可能不够清晰，表达不够准确，频繁的人员更迭会导致很多代码的缺陷需要后续新人深入代码中查找跟踪，要熟悉一个单体应用需要耗费大量时间。
● 维护成本高：随着单体应用的扩展，开发人员增多，沟通成本和管理成本迅速增长。一个问题出现时，往往需要几人协作才可以确定，并且一个问题的修复往往又牵扯到其他模块的其他问题，维护成本越来越高。
● 交付周期不可控性增大：开发和运维越来越难，部署的周期也随着单体应用的复杂而变得问题频发，常常出现越临近上线问题越多的情况。
● 技术选型难度高：单体架构倾向于一个整体框架可复制性地解决所有问题，所以在技术选型期间需要进行认真细致的评估，难度非常大。
● 可扩展性差：很多模型都是复用的，扩展应用时大概率会影响到原有服务，让扩展的工作变得颇为艰巨。
垂直架构
因为单体架构存在种种缺点，所以软件工程领域开始思考如何优化，垂直架构应运而生。垂直架构和单体架构最大的区别就在于对系统进行了划分，按照业务的独立性分为了不同的子单体。
可以说，垂直架构是在最大化使用了单体架构优势的基础上进行的优化，这种架构有不少优点，如下：
● 分拆为多个项目，边界清晰。
● 各项目规模可控，不至于无限扩展。
● 不同的垂直结构可以采用不同的技术架构。
● 和单体架构非常相似，方便开发人员去理解。
但是，这种架构也有着非常明显的缺点：
● 项目与项目之间存在着数据冗余，耦合性大，可能几个项目中都是用同一个表。
● 系统的性能提高只能依靠增加集群，成本比较高。
● 项目之间需要很多接口在彼此间同步数据。
所以，架构继续演进，又有了下面的SOA架构。
SOA
SOA（Service-Oriented Architecture）是面向服务的架构，这是在垂直架构的基础上发展而来的一种架构。这个概念非常好理解，当垂直架构越来越多的时候，核心业务彼此之间的交互越来越多，所以就把核心的业务抽取出来做成独立的服务，并且形成服务中心。
SOA的重点是通过ESB（Enterprise Service Bus）企业服务总线来提供服务的，并不关心服务之间彼此是否完全切分。
SOA架构有很多优点，简单梳理如下：
● SOA可以将重要的功能提取成服务，避免重复开发。
● 采用ESB减少了系统之间的繁杂接口。
● 各个项目之间可以采用标准的Webservice或RPC进行调用。
其实到目前为止也有很多项目是采用这种架构的，之所以现在慢慢地开始转向微服务架构，是因为SOA有以下缺点：
● 各个服务之间并没有彻底的组件化，维护过程中仍然可能彼此影响，增加维护成本。
● ESB的方式过重，内部包含各种协议，随着项目增大，运维难度增加。
最后，就演进到现在的微服务架构了。
微服务架构
重点来看一下微服务的特征：
● 职责唯一性：微服务中的每个服务都是单一的，或者说在整个架构中是唯一的。每个服务都是高内聚、低耦合的设计。
● 通信轻量级：服务之间的通信采用轻量级的实现，就是说通信的实现与具体语言、平台无关。比如，比较常用的数据交换格式包括XML、JSON等，都是与平台和语言无关的，REST（Representational State Transfer）也是常用的轻量级通信方式之一。
● 独立性：独立性指每个单个服务在开发、测试和部署过程中都是独立的，不受其他服务影响，也不会影响到其他服务。
● 进程隔离：每个微服务都运行在自己独立的进程中，有独立的运行时环境，可以方便地部署在不同的机器上。
微服务架构能够成为当前演进出的最先进框架，并非偶然，下面梳理一下微服务的优点。
● 开发效率高：微服务将庞大复杂的系统进行拆分，每个微服务都变得功能单一，易于理解和方便开发，确保每个微服务的开发都很高效。
● 新增需求响应快：因为对于服务的充分拆分，每个新的服务开发都非常高效，响应新需求非常快，非常适合敏捷开发。
● 部署更方便：单个微服务的部署并不影响全局，特别是如果一个微服务运行在多个实例上，完全可以做到部署的同时向客户提供服务。
微服务肯定同样存在缺点，下面来了解一下。
● 运维难度增加：微服务的服务接口一般都是数量比较多的，因为数量太多，所以在整个服务出现问题的时候，要找出具体是哪个微服务出了问题是有难度的。要想象在单体应用里面一样通过单步的debug追溯原因是不可能的，可想而知，对运维团队的要求也就增加了。
● 分布式部署难度增加：微服务是天然分布式的，也是因为必须采用分布式，所以部署和调度管理的难度就增加了。▪接口修改成本高：因为众多微服务之间是彼此调用的，所以当一个微服务接口要进行修改调整的时候，依赖该接口的其他众接口都需要检查或修改。因此，接口的修改成本增加。
● 部分代码重复：因为每个微服务的开发、测试和部署都是独立的，运行时环境也是独立的，所以造成很多重复性的功能在每个微服务中都要重复开发。
对单体架构和微服务架构的对比分析如下图。
