**
一、单体架构VS微服务架构**
1. 单体架构
从单体架构说起的话,单体架构就是一个工程对应一个war包(归档包),是我们常说的单体架构(一个 war包打天下)。 具体描述: 就是在我们的一个war包种,聚集了各种功能以及资源,比 如JSP JS,CSS等。而业务种包含了我们的用户模块,订单模块,支付模块等 等
单体架构的优缺点:
优点:
①: 架构简单明了,没有”花里胡哨“的问题需要解决。
②:开发,测试,部署简单(尤其是运维人员 睡着都会笑醒 哈哈~)
缺点:
①:随着业务扩展,代码越来越复杂,代码质量参差不齐(开发人员的 水平不一),会让你每次提交代码 ,修改每一个小bug都是心惊胆战 的。
②:部署慢(由于单体架构,功能复杂) 能想像下一个来自200W+代码部 署的速度 (15分钟)
③:扩展成本高
1. 微服务以及微服务架构
-
微服务的核心
微服务核心就是把传统的单机应用,根据业务将单机应用拆分 为一个一个的服务,彻底的解耦,每一个服务都是提供特定的功能,一 个服务只做一件事,类似进程,每个服务都能够单独部署,甚至可以拥 有自己的数据库。这样的一个一个的小服务就是 微服务.
①: 比如传统的单机电商应用, tulingshop(tuling电商系统是一套基于Dubbo的大型分布式、高可用电商平台,可用于互联网电子商务、企业电子商务、互联网医疗、以及大型互联网门户等系统。已备注,可查看) 里面有 订单/支付/库存/物 流/积分等模块(理解为servcie)
②:我们根据 业务模型来拆分,可以拆分为 订单服务,支付服务,库存 服务,物流服务,积分服务
③若不拆分的时候,我的非核心业务积分模块 出现了重大bug 导致 系统内存溢出,导致整个服务宕机. ,若拆分之后,只是说我的积分微服务不可用,我的整个系统核心功能 还是能使用 -
微服务架构是什么?
微服务架构是一个架构风格, 提倡
①:将一个单一应用程序开发为一组小型服务.
②:每个服务运行在自己的进程中
③:服务之间通过轻量级的通信机制
④:每个服务都能够独立的部署
⑤:每个服务甚至可以拥有自己的数据库 1.4.5)微服务以及微服务架构的是二个完全不同的概念。 微服务强调的是服务的大小和对外提供的单一功能,而微服务架构是指 把 一个一个的微服务组合管理起来,对外提供一套完整的服务。 -
微服务的优缺点
A:优点:
①:每个服务足够小,足够内聚,代码更加容易理解,专注一个业务功能 点(对比传统应用,可能改几行代码 需要了解整个系统)
②: 开发简单,一个服务只干一个事情。(加入你做支付服务,你只要 了解支付相关代码就可以了)
③: 微服务能够被2-5个人的小团队开发,提高效率
④: 按需伸缩
⑤: 前后段分离, 作为java开发人员,我们只要关系后端接口的安全性 以及性能,不要去关注页面的人机交互(H5工程师)根据前后端接口协 议,根据入参,返回json的回参
⑥:一个服务可用拥有自己的数据库。也可以多个服务连接同一个数据 库.
B:缺点:
①:增加了运维人员的工作量,以前只要部署一个war包,现在可能需要 部署成百上千个war包
②: 服务之间相互调用,增加通信成本
③:数据一致性问题(分布式事物问题)
④:系能监控等,问题定位… -
微服务的适用场景
A:合适
①:大型复杂的项目…(来自单体架构200W行代码的恐惧)
②:快速迭代的项目…(来自一天一版的恐惧)
③:并发高的项目…(考虑弹性伸缩扩容的恐惧)
B:不合适
①:业务稳定,就是修修bug ,改改数据
②:迭代周期长 发版频率 一二个月一次.