微服务架构的前世此生（二）：技术架构的演变
上一篇咱们讲了微服务架构的前世此生（一）：传统行业向互联网行业的转型，本文接着讲述微服务技术架构演变。java
下图表示从单体应用逐渐转变为微服务应用。
spring
1、单一应用架构
通俗地讲，“单体应用（monolith application）”就是将应用程序的全部功能都打包成一个独立的单元。当网站流量很小时，只需一个应用，将全部功能都部署在一块儿，以减小部署节点和成本。数据库
一、特色
全部的功能集成在一个项目工程中；
全部的功能打一个 war 包部署到服务器；
应用与数据库分开部署；
经过部署应用集群和数据库集群来提升系统的性能。编程
二、优势
「开发简单」：一个 IDE 就能够快速构建单体应用；后端
「便于共享」：单个归档文件包含全部功能，便于在团队之间以及不一样的部署阶段之间共享；服务器
「易于测试」：单体应用一旦部署，全部的服务或特性就均可以使用了，这简化了测试过程，由于没有额外的依赖，每项测试均可以在部署完成后马上开始；网络
「容易部署」：整个项目就一个 war 包，Tomcat 安装好以后，应用扔上去就好了。群化部署也很容易，多个 Tomcat + 一个 Nginx 分分钟搞定。架构
三、缺点
「妨碍持续交付」：随着时间的推移，单体应用可能会变得比较大，构建和部署时间也相应地延长，不利于频繁部署，阻碍持续交付。在移动应用开发中，这个问题会显得尤其严重；并发
「不够灵活」：随着项目的逐渐变大，整个开发流程的时间也会变得很长，即便在仅仅更改了一行代码的状况下，软件开发人员须要花费几十分钟甚至超过一个小时的时间对全部代码进行编译，并接下来花费大量的时间从新部署刚刚生成的产品，以验证本身的更改是否正确。若是多个开发人员共同开发一个应用程序，那么还要等待其余开发人员完成了各自的开发。这下降了团队的灵活性和功能交付频率；app
「受技术栈限制」：项目变得愈来愈大的同时，咱们的应用所使用的技术也会变得愈来愈多。这些技术有些是不兼容的，就好比在一个项目中大范围地混合使用 C++ 和 Java 几乎是不可能的事情。在这种状况下，咱们就须要抛弃对某些不兼容技术的使用，而选择一种不是那么适合的技术来实现特定的功能。
「可靠性差」：某个环节出现了死循环，致使内存溢出，会影响整个项目挂掉。
伸缩性差：系统的扩容只能针对应用进行扩容，不能作到对某个功能进行扩容，扩容后必然带来资源浪费的问题。
「技术债务」：假设个人代码库中有一个混乱的模块结构。此时，我须要添加一个新功能。若是这个模块结构清晰，可能我只须要2天时间就能够添加好这个功能，可是现在这个模块的结构很混乱，因此我须要4天时间。多出来的这两天就是债务利息。随着时间推移、人员变更，技术债务必然也会随之增多。
2、垂直应用架构
当访问量逐渐增大，单一应用增长机器带来的加速度愈来愈小，将应用拆成互不相干的几个应用，以提高效率。
一、特色
以单体结构规模的项目为单位进行垂直划分，就是将一个大项目拆分红一个一个单体结构项目。
项目与项目之间存在数据冗余，耦合性较大，好比上图中三个项目都存在用户信息。
项目之间的接口多为数据同步功能，如：数据库之间的数据库，经过网络接口进行数据库同步。
二、优势
开发成本低，架构简单；
避免单体应用的无限扩大；
系统拆分实现了流量分担，解决了并发问题；
能够针对不一样系统进行扩容、优化；
方便水平扩展，负载均衡，容错率提升；
不一样的项目可采用不一样的技术；
系统间相互独立。
三、缺点
系统之间相互调用，若是某个系统的端口或者 IP 地址发生改变，调用系统须要手动变动；
垂直架构中相同逻辑代码须要不断的复制，不能复用。
系统性能扩展只能经过扩展集群结点，成本高、有瓶颈。
3、SOA 面向服务架构
当垂直应用愈来愈多，应用之间交互不可避免，将核心业务抽取出来，做为独立的服务，逐渐造成稳定的服务中心。当服务愈来愈多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增长一个调度中心基于访问压力实时管理集群容量，提升集群利用率。
P.S.：从软件设计的角度上来讲，ESB 是一个抽象的间接层，提取了服务调用过程当中调用与被调用动态交互中的一些共同的东西，减轻了服务调用者的负担。Java 编程思想里提到：“全部的软件设计的问题均可以经过增长一个抽象的间接层而获得解决或者获得简化！”简单来讲 ESB 就是一根管道，用来链接各个服务节点。为了集成不一样系统，不一样协议的服务，ESB 作了消息的转化解释和路由工做，让不一样的服务互联互通。
一、特色
基于 SOA 的架构思想将重复公用的功能抽取为组件，以服务的形式给各系统提供服务。
各项目（系统）与服务之间采用 WebService、RPC 等方式进行通讯。
使用 ESB 企业服务总线做为项目与服务之间通讯的桥梁。
二、优势
将重复的功能抽取为服务，提升开发效率，提升系统的可重用性、可维护性。
能够针对不一样服务的特色制定集群及优化方案；
采用 ESB 减小系统中的接口耦合。
三、缺点
系统与服务的界限模糊，不利于开发及维护。
虽然使用了 ESB，可是服务的接口协议不固定，种类繁多，不利于系统维护。
抽取的服务的粒度过大，系统与服务之间耦合性高。
涉及多种中间件，对开发人员技术栈要求高。
服务关系复杂，运维、测试部署困难
4、微服务架构
一、特色
将系统服务层彻底独立出来，并将服务层抽取为一个一个的微服务。
微服务中每个服务都对应惟一的业务能力，遵循单一原则。
微服务之间采用 RESTful 等轻量协议传输。
二、优势
团队独立：每一个服务都是一个独立的开发团队，这个小团队能够是 2 到 5 人的开发人员组成；
技术独立：采用去中心化思想，服务之间采用 RESTful 等轻量协议通讯，使用什么技术什么语言开发，别人无需干涉；
先后端分离：采用先后端分离开发，提供统一 Rest 接口，后端不用再为 PC、移动端开发不一样接口；
数据库分离：每一个微服务都有本身的存储能力，能够有本身的数据库。也能够有统一数据库；
服务拆分粒度更细，有利于资源重复利用，提升开发效率；
一个团队的新成员可以更快投入生产；
微服务易于被一个开发人员理解，修改和维护，这样小团队可以更关注本身的工做成果。无需经过合做才能体现价值；
能够更加精准的制定每一个服务的优化方案（好比扩展），提升系统可维护性；
适用于互联网时代，产品迭代周期更短。
三、缺点
微服务过多，服务治理成本高，不利于系统维护；
分布式系统开发的技术成本高（网络问题、容错问题、调用关系、分布式事务等），对团队挑战大；
微服务将原来的函数式调用改成服务调用，不论是用 rpc，仍是 http rest 方式，都会增大系统总体延迟。这个是再所不免的，这个就须要咱们将原来的串行编程改成并发编程甚至异步编程，增长了技术门槛；
多服务运维难度，随着服务的增长，运维的压力也在增大；
测试的难度提高。服务和服务之间经过接口来交互，当接口有改变的时候，对全部的调用方都是有影响的，这时自动化测试就显得很是重要了，若是要靠人工一个个接口去测试，那工做量就太大了，因此 API 文档的管理尤其重要。
本文就介绍到这里，想获取java微服务架构学习视频资料，请点击访问java微服务架构spring全家桶教程。
下一篇文章将分享2个故事，帮助你们更好的理解 SOA 与微服务的区别。