微服务 & 微服务架构
2023-10-18 11:55:01 1 举报AI智能生成
微服务微服务架构
作者其他创作
大纲/内容
1：单体架构 VS 微服务架构
单体架构
在我们的一个war包中，聚集了各种功能以及资源，比 如JSP JS,CSS等。而业务种包含了我们的用户模块，订单模块，支付模块等 等
单体架构优缺点总结
优点
①: 架构简单明了，没有”花里胡哨“的问题需要解决
②:开发，测试，部署简单（尤其是运维人员 睡着都会笑醒）
缺点
①：随着业务扩展，代码越来越复杂，代码质量参差不齐(开发人员的 水平不一),会让你每次提交代码 ，修改每一个小bug都是心惊胆战 的
②:部署慢(由于单体架构，功能复杂) 能想像下一个来自200W+代码部 署的速度 (15分钟)
③:扩展成本高，根据单体架构图 假设用户模块是一个CPU密集型的模 块(涉及到大量的运算)那么我们需要替换更加牛逼的CPU，而我们的订 单模块是一个IO密集模块（涉及大量的读写磁盘）,那我们需要替换更 加牛逼的内存以及高效的磁盘。但是我们的单体架构上 无法针对单个 功能模块进行扩展，那么就需要替换更牛逼的CPU 更牛逼的内存 更牛 逼的磁盘 价格蹭蹭的往上涨。
④:阻碍了新技术的发展。。。。。。比如我们的web架构模块 从 struts2迁移到springboot，那么就会成为灾难性
微服务以及微服务架构
微服务的定义
中文:http://blog.cuicc.com/blog/2015/07/22/microservices
微服务核心
就是把传统的单机应用，根据业务将单机应用拆分 为一个一个的服务，彻底的解耦，每一个服务都是提供特定的功能，一 个服务只做一件事,类似进程，每个服务都能够单独部署，甚至可以拥 有自己的数据库。这样的一个一个的小服务就是 微服务
①: 比如传统的单机电商应用, tulingshop 里面有 订单/支付/库存/物 流/积分等模块(理解为servcie)
②:我们根据 业务模型来拆分,可以拆分为 订单服务，支付服务，库存 服务，物流服务，积分服务
③若不拆分的时候，我的非核心业务积分模块 出现了重大bug 导致 系统内存溢出，导致整个服务宕机. ,若拆分之后，只是说我的积分微服务不可用，我的整个系统核心功能 还是能使用
微服务架构是一个架构风格, 提倡
①:将一个单一应用程序开发为一组小型服务.
②:每个服务运行在自己的进程中
③:服务之间通过轻量级的通信机制(http rest api)
④:每个服务都能够独立的部署
⑤:每个服务甚至可以拥有自己的数据库
微服务以及微服务架构的是二个完全不同的概念
微服务强调的是服务的大小和对外提供的单一功能
微服务架构是指 把 一个一个的微服务组合管理起来，对外提供一套完整的服务。
微服务的优缺点
优点
①：每个服务足够小,足够内聚，代码更加容易理解,专注一个业务功能 点(对比传统应用，可能改几行代码 需要了解整个系统)
②: 开发简单，一个服务只干一个事情。（加入你做支付服务，你只要 了解支付相关代码就可以了）
③: 微服务能够被2-5个人的小团队开发，提高效率
④: 按需伸缩
⑤: 前后段分离, 作为java开发人员，我们只要关系后端接口的安全性 以及性能，不要去关注页面的人机交互(H5工程师)根据前后端接口协 议，根据入参，返回json的回参
⑥:一个服务可拥有自己的数据库。也可以多个服务连接同一个数据 库
0 条评论
下一页
