单体架构是最简单的架构,常见于常见于传统的web开发,将前端代码和所有业务代码放在一个系统里,统一打包并运行,比如传统的J2EE应用,将代码打包成war, 部署在Jboos或tomcat容器中运行。
单体应用存在的问题主要有以下几个:
SOA的架构也就是面向服务的架构,是单体架构经过水平拆分和垂直拆分的结果,按功能进行抽取代码,独立成各个服务,个服务独立部署,各个服务之间采用统一的协议进行通信。
各服务之间需要调用,引入ESB来管理项目, 可以通过webservice或rpc来实现。
SOA架构存在的问题主要有以下几个:
微服务也是一种服务化,是基于SOA进一步演进而来的更轻量级的服务化。它主要特点包括:
松耦合: 每个微服务内部都可以使用DDD(领域驱动模型)来设计,服务间尽量减少同步调用,多使用消息的方式让服务之间通过领域时间来通信。
轻量级协议:微服务之间更倾向于使用Restful风格的API, 并且各个服务可以用不同语言实现,对于性能要求极高的场景,可以使用protobuff协议。
高度自治和持续集成: 微服务可以很好的和容器化结合,微服务通过docker容器独立部署,互相独立,可以更好地进行扩容或缩容,提升了伸缩性。 并且微服务可以和devops结合,CICD和运维监控都很方便。
前后端分离: 这样前后端分工明确,更专注与各自的分工,最终提供的服务体验更佳。
无状态服务: 将业务服务变成无状态的计算服务,专注于业务逻辑,将有状态的信息存放在DB或缓存中。
REST通信风格: 1. http天然的无状态协议,结合Json,可读性较好,如果需要安全加密,有现成的https协议可用。 2. 语言无关,大部分语言都有成熟的Restful api框架可用。3. 一些特殊场景,采用rpc框架,如grpc, thrift等。
项目 | 单体架构 | 微服务架构 |
---|---|---|
迭代速度 | 较慢 | 快 |
部署频率 | 不经常 | 频率快,可以每天发布 |
系统性能 | 吞吐量小 | 吞吐量大 |
扩展性 | 差 | 好 |
技术栈多样性 | 单一封闭 | 多样且开放 |
运维 | 简单 | 运维复杂 |
部署难度 | 容易 | 较难 |
定位问题难度 | 容易 | 困难 |
管理成本 | 主要在开发成本 | 服务治理和运维成本 |
可以看到,微服务虽然带来了好处,同时也带了了一些复杂性,包括: