1)5分钟谈微服务架构

本文介绍了单体架构与微服务架构的对比,强调微服务的解耦特性及其带来的开发、部署和扩展优势。在单体架构中,随着业务增长,代码复杂性和维护难度增加,而微服务则通过拆分服务实现独立部署和伸缩。然而,微服务也带来了运维复杂性、服务间通信成本和数据一致性等问题。适合大型、快速迭代和高并发项目的微服务架构,对于稳定且迭代周期长的项目可能并不适用。
摘要由CSDN通过智能技术生成

一:微服务 & 微服务架构

1:单体架构 VS 微服务架构

1.1)从单体架构说起

一个工程对应一个归档包(war),这个war包 包含了该工程的所有功能。我们成为这 种应用为单体应用,也就是我们常说的单体架构(一个war包打天下)。

具体描述: 就是在我们的一个war包种,聚集了各种功能以及资源,比如JSP JS,CSS等。而业务种包含了我们的用户模块,订单模块,支付模块等等。

1.2)单体应用架构图

1.3)单体架构优缺点总结

优点:

①: 架构简单明了,没有”花里胡哨“的问题需要解决。

②:开发,测试,部署简单(尤其是运维人员 睡着都会笑醒)

缺点:

①:随着业务扩展,代码越来越复杂,代码质量参差不齐(开发人员的水平不一),会让 你每次提交代码 ,修改每一个小bug都是心惊胆战的。

②:部署慢(由于单体架构,功能复杂) 能想像下一个来自200W+代码部署的速度 (15分钟)

③:扩展成本高,根据单体架构图 假设用户模块是一个CPU密集型的模块(涉及到大量 的运算)那么我们需要替换更加牛逼的CPU,而我们的订单模块是一个IO密集模块(涉 及大量的读写磁盘),那我们需要替换更加牛逼的内存以及高效的磁盘。但是我们的单 体架构上 无法针对单个功能模块进行扩展,那么就需要替换更牛逼的CPU 更牛逼的内 存 更牛逼的磁盘 价格蹭蹭的往上涨。

④:阻碍了新技术的发展。。。。。。比如我们的web架构模块 从struts2迁移到 springboot,那么就会成为灾难性

1.4)微服务以及微服务架构

1.4.1)微服务的定义

①: 英文:https://martinfowler.com/articles/microservices.html

②: 中文:http://blog.cuicc.com/blog/2015/07/22/microservices

1.4.2)微服务核心就是把传统的单机应用,根据业务将单机应用拆分为一个一个的服 务,彻底的解耦,每一个服务都是提供特定的功能,一个服务只做一件事,类似进程, 每个服务都能够单独部署,甚至可以拥有自己的数据库。这样的一个一个的小服务就 是 微服务.

①: 比如传统的单机电商应用, tulingshop 里面有 订单/支付/库存/物流/积分等模块(理 解为servcie)

②:我们根据 业务模型来拆分,可以拆分为 订单服务,支付服务,库存服务,物流服 务,积分服务

*③*若不拆分的时候,我的非核心业务积分模块 出现了重大bug 导致系统内存溢出, 导致整个服务宕机. ,若拆分之后,只是说我的积分微服务不可用,我的整个系统核心功能还是能使用

1.4.3)单机架构扩展与微服务扩展

①:单机架构扩展

②:微服务架构以及扩展

③:微服务数据存储

1.4.4)微服务架构是什么?

微服务架构是一个架构风格, 提倡

①:将一个单一应用程序开发为一组小型服务.

②:每个服务运行在自己的进程中

③:服务之间通过轻量级的通信机制(http rest api)

④:每个服务都能够独立的部署

⑤:每个服务甚至可以拥有自己的数据库

1.4.5)微服务以及微服务架构的是二个完全不同的概念。

微服务强调的是服务的大小和对外提供的单一功能,而微服务架构是指把 一个一个的 微服务组合管理起来,对外提供一套完整的服务。

1.4.6)微服务的优缺点

A:优点:

①:每个服务足够小,足够内聚,代码更加容易理解,专注一个业务功能点(对比传统应 用,可能改几行代码 需要了解整个系统)

②: 开发简单,一个服务只干一个事情。(加入你做支付服务,你只要了解支付相关代 码就可以了)

③: 微服务能够被2-5个人的小团队开发,提高效率

④: 按需伸缩

⑤: 前后段分离, 作为java开发人员,我们只要关系后端接口的安全性以及性能,不要 去关注页面的人机交互(H5工程师)根据前后端接口协议,根据入参,返回json的回参

⑥:一个服务可用拥有自己的数据库。也可以多个服务连接同一个数据库.

缺点:

①:增加了运维人员的工作量,以前只要部署一个war包,现在可能需要部署成百上千 个war包 (k8s+docker+jenkis )

②: 服务之间相互调用,增加通信成本

③:数据一致性问题(分布式事物问题)

④:系能监控等,问题定位..........................

1.4.6)微服务的适用场景

A:合适

①:大型复杂的项目............(来自单体架构200W行代码的恐惧)

②:快速迭代的项目............(来自一天一版的恐惧)

③:并发高的项目................(考虑弹性伸缩扩容的恐惧)

B:不合适

①:业务稳定,就是修修bug ,改改数据

②:迭代周期长 发版频率 一二个月一次.

 

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

宇哥哦

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值