单体架构是什么
- 一个归档包包含了应用所有功能的应用程序,我们通常称为单体应用。
- 架构单体应用的架构风格,我们称为单体架构,这是一种比较传统的架构风格。
单体架构存在的缺点
- 复杂性逐渐变高
成功的应用最终会随着时间变得巨大。在每个 sprint 阶段,开发团队都会新加许多行代码。几年后,原本小而简单的应用会变得臃肿。举个极端的例子,我最近与一位开发者交流,他正在开发一款小工具,来分析他们应用(包括几百万行代码)中的几千个 JARs 的依赖。我相信每年都会有大量开发者不遗余力地对付这种麻烦。
- 技术债务逐渐上升
一旦你的应用变得庞大、复杂,你的开发团队将饱受折磨,苦苦挣扎于敏捷开发和交付。一大原因就是应用已经格外复杂,庞大到任何一个开发者都无法完全理解。最后,修复 bug 和实施新功能也就极其困难且耗时颇多。更可怕的是,这是一个向下的螺旋发展。代码库越难理解,正确的修改就越难。最后你会深陷庞大的、无法估量的泥淖之中。
- 部署速度逐渐变慢
而这种应用的尺寸也会拖慢开发进度。应用越大,启动时间越长。譬如在最近的调查中,不少开发者指出启动时间长达 12 分钟。我也听说有的应用启动时间居然得 40 分钟。如果开发者不得不频繁重启应用服务器,那大量时间就被浪费,生产效率也饱受其害。
- 阻碍技术创新
庞大且复杂的单体应用的另一大问题就是难以进行持续部署。现在, SaaS 应用的发展水平足以在单日内多次将修改推送到生产环境。然而要让复杂的单个应用达到此水平却极为棘手。想更新应用的单个部分,必须重新部署整个应用,漫长的启动时间更是雪上加霜。另外,由于不能完全预见修改的影响,你不得不提前进行大量人工测试。结果就是,持续部署变得不可能。
- 无法按需伸缩(对资源的要求)
如果单体应用的不同模块在资源需求方面有冲突的话,那应用的扩展也很难。比如,模块之一需要执行 CPU-intensive 图像处理逻辑,最好部署到 AWS 的 EC2 Compute Optimized instances;而另一模块需要内存数据库,最好适配 EC2 Memory-optimized instances。由于这两个模块需要共同部署,你不得不在在硬件选择方面做妥协。
- 可靠性低
单体应用的另一问题就是可靠性。由于所有模块都运行在同一进程中,任何模块中的一个 bug,比如内存泄漏都可能弄垮整个进程;此外,由于应用中的所有实例都是唯一,这个 bug 将影响整个应用的可用性。
- 技术更新困难
单体应用会让采用新框架和语言极其困难。举例来说,你有两百万行使用 XYZ 框架的代码,如果要使用 ABC 框架重写代码,无论时间还是成本都将非常高昂,即便新框架更好。这也就成为使用新技术的阻碍。
什么是微服务
- Martin Fowler:简而言之,微服务架构风格的这种开发方法,是以开发一组小型服务的方式来进行开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中,并经常采用HTTP资源API这样轻量的机制来相互通讯。这些服务围绕着业务功能来进行构建,并能通过全自动的部署来进行独立部署。这些微服务可以使用不同的语言来编写,并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
微服务具备的特性
- 每个微服务可以独立的运行在自己的进程里;
- 一系列独立运行的微服务共同构建起了整个系统;
- 每个服务为独立的业务开发,一个微服务一般完成某个特定的功能,比如:订单管理,用户管理等;
- 微服务之间通过一些轻量级的通讯机制进行通讯,例如通过REST API或者RPC(远程过程调用协议)的方式进行调用;
微服务的优点
- 易于开发和维护
- 启动较快
- 局部修改容易部署
- 技术栈不受限
- 按需伸缩
- DevOps
微服务带来的挑战
- 运维要求较高
- 分布式的复杂性
- 接口调整成本高
- 重复劳动(存在重复性的代码)
微服务设计原则
- 单一职责原则
- 服务自治原则
- 轻量级通讯原则(跨平台\跨技术栈)
- 接口明确原则
微服务开发框架
- Spring Cloud
- Dubbo:服务治理
- Dropwizard:单个微服务
- Consl、etcd&etc
- 本文作者: 半度微凉
- 本文链接: http://www.taoweidong.com/2018/01/17/SpringCloud微服务笔记-微服务架构概述/
- 版权声明: 本博客所有文章除特别声明外,均采用 Apache License 2.0 许可协议。转载请注明出处!