建网站需要什么,广州建设官方网站,中山网站建设服务,安庆网站建设今天准备开始学习微服务#xff0c;使用微服务肯定是因为他有好处。
首先了解到的三种架构#xff0c;传统单体#xff0c;集群架构#xff0c;微服务架构
单体架构
有单点问题#xff0c;如果宕机所有的服务都不可用所有业务的功能模块都聚集在一起#xff0c;如果代…今天准备开始学习微服务使用微服务肯定是因为他有好处。
首先了解到的三种架构传统单体集群架构微服务架构
单体架构
有单点问题如果宕机所有的服务都不可用所有业务的功能模块都聚集在一起如果代码量多功能之前如果有很多共同的代码不同业务的需求开发同时进行的时候维护起来有点麻烦由于是单体对请求的并发量有限制一个tomcat并发量千级左右由于代码都聚集在一起部署慢修改bug牵扯的可能性的代码有很多修个bug可能需要把所有功能模块都测试一遍扩展成本高根据单体架构图 假设用户模块是一个CPU密集型的模块(涉及到大量的运算)那么我们需要替换更加牛逼的CPU而我们的订单模块是一个IO密集模块涉及大量的读写磁盘,那我们需要替换更加牛逼的内存以及高效的磁盘。但是我们的单体架构上 无法针对单个功能模块进行扩展那么就需要替换更牛逼的CPU 更牛逼的内存 更牛逼的磁盘 价格蹭蹭的往上涨。前后端不分离后端开发人员可能要具备相应的前端知识 适用于
业务稳定运行稳定就是修修bug 改改数据迭代周期长 发版频率 一二个月一次.
集群架构
集群架构只是改善了单体架构的单点故障问题和提高请求的并发数并通过ngnix负载均衡 微服务
微服务核心就是把传统的单机应用根据业务将单机应用拆分为一个一个的服务彻底的解耦每一个服务都是提供特定的功能一个服务只做一件事,类似进程每个服务都能够单独部署甚至可以拥有自己的数据库。这样的一个一个的小服务就是 微服务. 微服务拆分原则
单一微服务高内聚微服务之间低耦合避免出现双向依赖环形依赖避免微服务之间频繁调用根据业务模块划分对数据库进行拆分针对应用性能拆分比如有些功能是CPU密集型应用如对大量数据进行频繁计算的模块对硬件要求比较高有些是IO密集型的对硬件成本要求不高的如文件上传下载服务应循序渐进的进行拆分避免应用实例爆发式的增长对部署测试都有一定的压力可以先把一些非核心业务进行依次拆分也避免影响日常的需求迭代服务接口要具备可拓展性微服务之间的调用接口参数应用统一对象来进行传参必要时对对象添加泛型的支持统一的序列化和反序列化方式服务拆分粒度要适中拆分粒度不是越细越好粒度需要符合弓箭原理及三个火枪手原则弓箭原理就是业务复杂度越高团队人员越多拆分出来的微服务可以越多三个火枪手原则是一个微服务2-3个人开发维护最合适
优点:
每个服务足够小,足够内聚代码更加容易理解,专注一个业务功能点(对比传统应用可能改几行代码 需要了解整个系统)开发简单一个服务只干一个事情。加入你做支付服务你只要了解支付相关代码就可以了 微服务能够被2-5个人的小团队开发提高效率按需伸缩一个服务可用拥有自己的数据库。也可以多个服务连接同一个数据库.
缺点:
增加了运维人员的工作量以前只要部署一个war包现在可能需要部署成百上千个war包 (k8sdockerjenkis )服务之间相互调用增加通信成本数据一致性问题(分布式事物问题)系能监控等,问题定位 微服务的适用场景
大型复杂的项目快速迭代的项目并发高的项目 版权声明本文借鉴CSDN博主「为爱停留」的原创文章。 原文链接https://blog.csdn.net/beiduofen2011/article/details/124101900
