欢迎访问Spring Cloud中国社区

我们致力于成为中国最专业的Spring Boot和Spring Cloud交流社区。推荐使用Github直接登录,欢迎加微信号Software_King进入社区微信交流群。若发现网站bug欢迎反馈!

单体架构、微服务对比特点及单体变微服务的策略

aspx5 · 24天前 · 293 ·

一、单体架构与微服务架构对比。

1、测试、部署问题:
单体架构:业务运行在一个进程中,因此系统中任何程序的改变,都需要对整个系统重新测试并部署。
微服务架构:每个微服务组件都是简单灵活的,能够独立部署。不像单体系统,需要一个庞大的应用服务器来支撑。

2、可伸缩性:
单体架构:单体架构系统由于单进程的局限性,水平扩展时只能基于整个系统进行扩展,无法针对某一个功能模块按需扩展。例如:电商系统,包含了 用户、商品、订单、交易、支付;如果商品的访问量非常大,我想对商品进行集群部署,这时你是无法做到,你只能对整个系统进行集群部署。
微服务架构:微服务之间是松耦合,微服务内部是高内聚,每个微服务很容易按需扩展。水平扩展只要按服务进行扩展即可。

3、可靠性:
单体架构:某个BUG,例如死循环、内存溢出,会导致整个进程宕机,影响整个系统,影响其他功能。
微服务架构:不会因为某个bug,而导致整个系统宕机。因为服务之间是松耦合的关系,不是强依赖。

4、系统迭代:
单体架构:由于所有的功能都在一个系统里面,会导致日常迭代相当困难,例如互联网项目,多个项目每月都有一次正常迭代,必定导致代码分支过多,分支合代码繁琐困难。
微服务架构:由一个小团队负责更专注专业,相应的也就更高效可靠。每个微服务可以由不同的团队独立开发。

5、跨语言程度:
单体架构:整个系统(甚至整个企业)统一的技术栈,管理起来看似简单。但有时候统一的标准并不适合所有的实际情况。
微服务架构:微服务架构与语言工具无关,自由选择合适的语言和工具,高效的完成业务目标即可。

6、团队协助:
单体架构:整个系统一个团队。如果系统变得庞大,成员就需要学习大量的代码和领域知识,团队内的沟通和协作也变得低效。
微服务架构:团队按微服务配置。成员专注于小的领域和代码集。沟通成本低。容易学习。

二、微服务架构带来的问题。

1、运维成本过高,部署物数量多、监控进程多导致整体运维复杂度提升。
2、接口兼容多版本(面向服务开发,就是面向接口开发,一般接口的变更,必然导致多个客户端要跟着改,那怎么办呢,就必须做接口的多版本开发)
3、分布式系统的复杂性(本来就一个系统,把他拆成多个服务,就会引发,网络延迟(因为网络不稳定)、服务容错性、服务的负载均衡等等)
4、分布式事务(微服务开发,带来的难题就是分布式事务的处理,关于分布式事务业界也有很多处理的方法)

三、单体变微服务的策略。

1、拆分:对应用进行水平和垂直拆分,例如商品中心、计费中心、订单中心等。
2、解耦:通过服务化和订阅、发布机制对应用调用关系解耦,支持服务的自动注册和发现。
3、透明:通过服务注册中心管理服务的发布和消费、调用关系。
4、独立:服务可以独立打包、发布、部署、启停、扩容和升级,核心服务独立集群部署。
5、分层:梳理和抽取核心应用、公共应用,作为独立的服务下沉到核心和公共能力层,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。