## **逃离单体地狱** ## 泥球模式 * 把这种软件比喻成“随意架构的，庞大的，草率的”布满了胶带和线路，如同意大利面条一般的代码丛林。软件交付的步伐已经放缓，更糟糕的是，应用程序是使用一些已经过时的框架编写的。 ## 典型的分层模块化企业级java应用 * 他由业务逻辑组成，业务逻辑外面是实现用户界面的适配器和与外部系统的接口。 * 业务逻辑有包含了服务和领域对象的模块组成，一些典型的模块若干适配器来完成与外部系统的对接工作，包括RESTAPI和web页面适配器。 *单体软件架构风格： 一个系统应用被作为单一的单元打包和部署->部署运行在Tomcat上 ## 单体架构的好处 * 应用的开发很简单，IDE和其他开发工具只需构建这一个单独的应用程序。 * 易于对应用程序进行大规模的更改（比如更改数据库模式） * 测试相对简单直观，（只需要对RESTAPI进行单元测试） * 部署简单明了，（以war的形式部署在Tomcat上） * 横向扩展不费吹灰之力，（一般使用ngixn进行横向水平扩展） ## 为什么逃离单体炼狱 * 显示更多功能是时，会导致代码库膨胀 * 敏捷开发和部署已经不可能 * 更改的代码提交到单个源代码库，从代码提交到生产环境，漫长而艰巨，并且涉及到手工测试，应用程序庞大，复杂，不可靠，难以维护 * 过渡的复杂度会吓退开发者（难以理解它的全部，修复比实现新功能更困难且耗时，而且会形成恶性循环） * 开发速度缓慢，（构建应用程序需要很长时间，从编辑到构建运行再到测试周期时间长） * 从代码提交到实际部署的周期很长，而且容易出错。 * 难以扩展（横向扩展）服务器需要较大的内存 * 交付可靠的单体应用是一项挑战（错误的代码进入生产环境程序缺少故障隔离，所有的代码都在一个行程运行） * 需要长期依赖某一个可能已经过时的技术栈 ## **拯救之道 微服务架构** * 软件架构对功能行需求影响不大，架构的重要行在于它影响了应用的非功能性需求，也称为质量属性或者其他的能力。 * 扩展了立方体和服务 * Y轴扩展又称为功能行分解，用过分解不同功能的方式来实现扩展 * X扩展 又称为水平复制通过克隆实例的方式扩展(负债均衡) * Z扩展，又称为数据分区，通过类似客户ID的方式吧相似的数据分区进行扩展 ## 微服务的定义 * 把应用程序功能性分解为一组服务的架构风格（模块化） * 微服务架构作为模块化的一种形式 * 模块化是开发大型复杂的应用程序的基础，大型应用需要拆分为模块 * 微服务架构使用服务作为模块化的单元，服务的API为自身构筑了一个可逾越的边界 * 服务可以独立部署和扩展 * 每个服务都拥有自己的数据库 * 微服务架构特性是每一个服务之间都是松耦合的，仅通过调用API的方式进行通信，在运行时服务实现类相互之间的独立，服务不会因为其他服务锁了数据库而进入堵塞的状态 ## 微服务架构的好处 * 使大型的复杂应用程序可以持续交付和持续部署 * 每个服务器都相对较小并容易维护 * 服务可以独立部署 * 微服务架构可以实现团队的自活 * 服务可以独立扩展 * 更容易试验和采纳新的技术 * 更好的容错性 ## 微服务的弊端 * 服务的拆分和定义是一个有难度的事情（重点） 1. * 服务的拆分没有一个衡量标准，没有算法可以完成服务拆分工作，一个不小心就构建出一个分布式的单体应用，一个包含了一大堆互相紧耦合的服务，这样会把单体架构的和微服务架构两者合一，弊端基于一身。 2. * 分布式系统带来的各种复杂性，使开发，测试和部署变得困难 * 多个服务的功能需要协调更多开发人员 * 开发者需要思考应该在应用的什么阶段使用微服务架构