下图表示从单体应用逐渐转变为微服务应用。
单一应用架构
通俗地讲，“单体应用（monolith application）”就是将应用程序的所有功能都打包成一个独立的单元。当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
特点
所有的功能集成在一个项目工程中；
所有的功能打一个 war 包部署到服务器；
应用与数据库分开部署；
通过部署应用集群和数据库集群来提高系统的性能。
优点：
开发简单：一个 IDE 就可以快速构建单体应用；
便于共享：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享；
易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始；
容易部署：整个项目就一个 war 包，Tomcat 安装好之后，应用扔上去就行了。群化部署也很容易，多个 Tomcat + 一个 Nginx 分分钟搞定。
缺点：
妨碍持续交付：随着时间的推移，单体应用可能会变得比较大，构建和部署时间也相应地延长，不利于频繁部署，阻碍持续交付。在移动应用开发中，这个问题会显得尤为严重；
不够灵活：随着项目的逐渐变大，整个开发流程的时间也会变得很长，即使在仅仅更改了一行代码的情况下，软件开发人员需要花费几十分钟甚至超过一个小时的时间对所有代码进行编译，并接下来花费大量的时间重新部署刚刚生成的产品，以验证自己的更改是否正确。如果多个开发人员共同开发一个应用程序，那么还要等待其他开发人员完成了各自的开发。这降低了团队的灵活性和功能交付频率；
受技术栈限制：项目变得越来越大的同时，我们的应用所使用的技术也会变得越来越多。这些技术有些是不兼容的，就比如在一个项目中大范围地混合使用 C++ 和 Java 几乎是不可能的事情。在这种情况下，我们就需要抛弃对某些不兼容技术的使用，而选择一种不是那么适合的技术来实现特定的功能。
可靠性差：某个环节出现了死循环，导致内存溢出，会影响整个项目挂掉。
伸缩性差：系统的扩容只能针对应用进行扩容，不能做到对某个功能进行扩容，扩容后必然带来资源浪费的问题。
技术债务：假设我的代码库中有一个混乱的模块结构。此时，我需要添加一个新功能。如果这个模块结构清晰，可能我只需要2天时间就可以添加好这个功能，但是如今这个模块的结构很混乱，所以我需要4天时间。多出来的这两天就是债务利息。随着时间推移、人员变动，技术债务必然也会随之增多。
垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
特点
以单体结构规模的项目为单位进行垂直划分，就是将一个大项目拆分成一个一个单体结构项目。
项目与项目之间存在数据冗余，耦合性较大，比如上图中三个项目都存在用户信息。
项目之间的接口多为数据同步功能，如：数据库之间的数据库，通过网络接口进行数据库同步。
优点
开发成本低，架构简单；
避免单体应用的无限扩大；
系统拆分实现了流量分担，解决了并发问题；
可以针对不同系统进行扩容、优化；
方便水平扩展，负载均衡，容错率提高；
不同的项目可采用不同的技术；
系统间相互独立。
缺点
系统之间相互调用，如果某个系统的端口或者 IP 地址发生改变，调用系统需要手动变更；
垂直架构中相同逻辑代码需要不断的复制，不能复用。
系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。
SOA 面向服务架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心。当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
P.S. 从软件设计的角度上来说，ESB 是一个抽象的间接层，提取了服务调用过程中调用与被调用动态交互中的一些共同的东西，减轻了服务调用者的负担。Java 编程思想里提到：“所有的软件设计的问题都可以通过增加一个抽象的间接层而得到解决或者得到简化！”简单来说 ESB 就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通。
特点
基于 SOA 的架构思想将重复公用的功能抽取为组件，以服务的形式给各系统提供服务。
各项目（系统）与服务之间采用 WebService、RPC 等方式进行通信。
使用 ESB 企业服务总线作为项目与服务之间通信的桥梁。
优点
将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。
可以针对不同服务的特点制定集群及优化方案；
采用 ESB 减少系统中的接口耦合。
缺点
系统与服务的界限模糊，不利于开发及维护。
虽然使用了 ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。
抽取的服务的粒度过大，系统与服务之间耦合性高。
涉及多种中间件，对开发人员技术栈要求高。
服务关系复杂，运维、测试部署困难
微服务架构
特点
将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。
微服务中每一个服务都对应唯一的业务能力，遵循单一原则。
微服务之间采用 RESTful 等轻量协议传输。
优点
团队独立：每个服务都是一个独立的开发团队，这个小团队可以是 2 到 5 人的开发人员组成；
技术独立：采用去中心化思想，服务之间采用 RESTful 等轻量协议通信，使用什么技术什么语言开发，别人无需干涉；
前后端分离：采用前后端分离开发，提供统一 Rest 接口，后端不用再为 PC、移动端开发不同接口；
数据库分离：每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库；
服务拆分粒度更细，有利于资源重复利用，提高开发效率；
一个团队的新成员能够更快投入生产；
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值；
可以更加精准的制定每个服务的优化方案（比如扩展），提高系统可维护性；
适用于互联网时代，产品迭代周期更短。
缺点
微服务过多，服务治理成本高，不利于系统维护；
分布式系统开发的技术成本高（网络问题、容错问题、调用关系、分布式事务等），对团队挑战大；
微服务将原来的函数式调用改为服务调用，不管是用 rpc，还是 http rest 方式，都会增大系统整体延迟。这个是再所难免的，这个就需要我们将原来的串行编程改为并发编程甚至异步编程，增加了技术门槛；
多服务运维难度，随着服务的增加，运维的压力也在增大；
测试的难度提升。服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了，所以 API 文档的管理尤为重要。
总结
分享两个小故事，帮助大家更好的理解 SOA 与微服务的区别。
故事一：
很久以前的一天，Martin 在跟好友的交流中悟到了一种很棒的架构设计。他总结了一下，然后告诉了好友，好友说，这不是新鲜东西，早有人总结了，叫做 SOA。
Martin 很高兴，开始在公司内外推广 SOA。结果，不停有人质疑和挑战他。
你这不是 SOA 吧？SOA 这里应该是如此这般的。对，这里我对 SOA 的理解是这样的。你看，这本 SOA 的书说的和你说的有出入。粒度？SOA 没有谈到这个呀，你这不是 SOA。分层跟 SOA 没有关系，你为什么要说这个呢？…
Martin 没办法，心一横，老子就叫它 Martin’s SOA。老子发明的词，老子就是最高权威，有最终解释权。还有谁不服？
同事们一看，这思想本身很不错，值得推广，但叫 Martin’s SOA 太没品了吧？还是要取个好一点的名字，最好还能跟 SOA 有某种暗示传承。干脆就叫 Microservices 好了，又新，又有服务含在其中。
Martin 忿忿地接受了这个建议，心里想着：娘的，明明就是 SOA，一群**非要逼我取个新名字。
后来 Martin 发现每次提一个东西就会收到旧恶傻势力对解释权的挑战，所以每次要提一个什么概念，都去发明一个新词，免得一群人在那一边质疑挑战，一边大谈“我的理解”。
这就是微服务、敏捷、精益企业、持续集成、持续交付背后的故事。
一个名词产生之后，命名者的解释权就会随着时间而弱化（比如 Cooper 发明的 Persona 就被无数设计师乱用）。敏捷已经有点烂了，等微服务也烂了，我们还会发明新词。
实在没辙，都是被逼的啊。
故事二：
话说1979年，又是一个春天，莆田乡下的赤脚医生吴大牛被改革的春风吹的心潮澎湃，说干就干，吴大牛趁着夜色朦胧找大队支书汇报了汇报思想，第二天就承包了村卫生室，开启了自己的在医疗圈的传奇历程。
乡村诊所大家都知道，没什么复杂的东东，房子只有一间，一个大柜台中间隔开，一半是诊疗兼候诊区，一半是药房，看病就直接找医生，如果前面有人就自己找个位子坐下，排队等一会，秩序倒也井然，看完病了医生直接给抓药，然后下一个继续，也不需要护士和药剂师，吴大牛一个人全部包办。
辛辛苦苦忙碌了十年，时间来到了八九年，又是一个春天，昔日的单身汉吴大牛已成为十里八乡的知名人物，媳妇娶上了不说，家里还增加了一对双胞胎儿子，二层的小洋房也甚是气派。可是也有烦心事，尽管乡村诊所扩大到了两间，媳妇还偶尔能去帮帮忙，但是医生还是只有自己一个，天天从早忙到晚挣的都是一份钱，想多挣点怎么办？吴大牛日思夜想，还真给他想出来一招，怎么办，扩大规模，多招几个医生一起干。原来吴大牛只能治头疼脑热和跌打损伤，现在新招了一个医科大学的毕业生刘小明专治感冒发烧，又从邻村请来了老大夫李阿花专治妇科病，现在一个普通的小诊所就变成了有三个独立科室加一个公共药房（吴大牛媳妇负责）的小医院了，吴大牛是外科主任兼院长，收入那可比之前翻了三番。人逢喜事精神爽，大牛院长请县里的书法名家为新医院书写了牌匾–“博爱医院”，挑了一个黄道吉日正式挂了上去。
一晃十年过去了，又是一个春天，吴大牛的博爱医院已经发展到了内科外科妇科五官科骨科生殖科六个科室，每个科室3到5名医生不等，也耗费巨资购进了血液化验B超等先进仪器，大牛院长也早已脱离了医疗一线，成为了专职的管理者，但是医院的大事小事大家都找他，就这三十多号员工搞的他每天是焦头烂额，想再扩大规模实在是有心无力了。要说还是大学生有水平，老部下刘小明给大牛院长献了一计，把各个科室独立出去，让各个科室主任自己管理，大牛院长只管科室之间的协调和医院发展的大事，这样既能调动基层的积极性，又能把大牛院长解放出来扩大生产抓大事谋大事，岂不妙哉？就这样，博爱医院的新一轮改革轰轰烈烈的展开了。
又是一个十年，又是一个春天，大牛院长已成为本地知名的企业家，博爱医院也发展到了二十三个科室数百名员工，发展中也出现了新问题，由于各个科室独立挂号、收费、化验，有的科室整天忙忙碌碌效益好，有的科室就相对平庸些，连分到的各种检查仪器都不能满负荷运行，整个医院养了不少闲人。这时候大牛院长视野也开阔了，请来了管理专家进行了顶层设计，把原来分散到各个科室的非核心服务全部收归集中管理，把原来二十三个挂号窗口整合为十个，二十三个收费窗口整合为八个，集中布设在一楼大厅为全院服务，还把分散在各个科室的检查仪器集中起来成立独立的检验科，也为全院服务，这样人人有活干，整个医院的服务能力又上了一个新台阶，这轮改革后博爱医院通过了各级部门的鉴定成为了远近驰名的三甲医院，吴大牛也摇身一变成为了博爱集团的CEO兼董事长，下一步就准备IPO上市了。
说到这里大家可能有点糊涂，这个跟微服务有嘛关系？大牛诊所的1.0阶段就相当于软件开发的单体结构，一个程序员打天下，从头编到尾，很难做大做强。大牛诊所的2.0阶段就相当于软件开发的垂直结构，各科室按照业务划分，很容易横向扩展。博爱医院的1.0阶段就相当于软件开发的SOA结构，除了药房（数据库）外各个服务独立提供（科室主任负责），但需要大牛院长（ESB总线）来协调。博爱医院的2.0阶段就相当于软件开发的微服务结构，公共服务院内共享，科室主任管理功能弱化（只管医生业务），优点是扩容方便，哪个部门缺人直接加，不用看上下游，资源利用率高，人员和设备效率高。
微服务就是将一个单体架构的应用按业务划分为一个个的独立运行的程序即服务，它们之间通过 HTTP 协议进行通信（也可以采用消息队列来通信，如 RabbitMQ，Kafaka 等），可以采用不同的编程语言，使用不同的存储技术，自动化部署（如 Jenkins）减少人为控制，降低出错概率。服务数量越多，管理起来越复杂，因此采用集中化管理。例如 Eureka，Zookeeper 等都是比较常见的服务集中化管理框架。
微服务是一种架构风格，架构就是为了解耦，实际使用的是分布式系统开发。一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。
一句话总结：微服务是 SOA 发展出来的产物，它是一种比较现代化的细粒度的 SOA 实现方式。
