工作两年,技术依然在小白附近徘徊,即使有一些进步,但也不值一提
两年的工作内容,几乎就是cv加一些简单的百度,从细节方面说,经历的细节不算多,从架构方面讲,自己远远达不到那个级别。
谷粒商城主要是看尚硅谷在B站的教程,由于项目成熟,从开发到部署很完整,百度的生态也很好,决定从0开始开发谷粒商城,直到部署上线。
该笔记虽然是从头开发,但并不会事无巨细的详解每一个部分,每一种技术,因为就是混也是混两年了,多少还是懂一些的,但是会从头到尾,从架构图,设计文档,sql,到重难点源码、命令都会记录
看到有一些朋友收藏了这篇文章,如果你也正打算做这个项目,欢迎大家私信我,我们可以互相沟通。
看这篇文章的话我还是不建议大家收藏,没什么意义,这就和大部分书架上的书一样,
希望可以有人看到第二篇,第三篇。。。,再来收藏,更有意义一些
谷粒商城系列文章最后更新时间,2023.3.28
这个事儿啊,总是会和自己当初想象的不一样,
最开始的想法是要记录每一步,后来发现有些东西太简单,不值得记录,
然后就打算说那就只记录最重要的,现在是到第10篇了,就这样一篇篇写下去,发现又有冲突了,
之前接触过一些es,做过一些笔记,觉得如果整合到谷粒商城太麻烦,所以还是跟之前的笔记做一个补充,等真正应用到谷粒商城的时候再来下一篇笔记
市面上有 5 种常见的电商模式 B2B、B2C、C2B、C2C、O2O;
B2B 模式 B2B (Business to Business), 是指商家与商家建立的商业关系。 如:阿里巴巴、八方资源网等
B2C 模式 B2C (Business to Consumer), 就是我们经常看到的供应商直接把商品卖给用户,即“商对客” 模式,也就是通常说的商业零售,直接面向消费者销售产品和服务。如:亚马逊、当当等
B2C平台:天猫、京东、一号店等
C2B 模式 C2B (Customer to Business),即消费者对企业。先有消费者需求产生而后有企业生产,即先 有消费者提出需求,后有生产企业按需求组织生产
C2C 模式 C2C (Customer to Consumer) ,客户之间自己把东西放上网去卖,如:淘宝,闲鱼
O2O 模式 O2O 即 Online To Offline,也即将线下商务的机会与互联网结合在了一起,让互联网成为线 下交易的前台。线上快速支付,线下优质服务。如:饿了么,美团,淘票票,京东到家
P2P:在线金融,贷款,如:网贷之家、人人聚财等。
谷粒商城是一个 B2C 模式的电商平台,销售自营商品给客户。
简而言之:拒绝大型单体应用
(以前是将所有的代码、页面包括sql语句等都写在一个应用里,这样会导致如果有一处代码出现问题,可能会导致整个项目都不能运行),
而我们就希望将大型单体应用基于业务边界
进行拆分,将大型单体应用拆分成不同的小模块
,每一个小模块我们就可以称为一个微服务
,这些模块合起来就相当于一个单体应用,这些微服务都是独立部署运行的,如果有一个出现了问题,我们不希望影响其他服务
的运行。
微服务是一种非常流行的架构风格,将大应用拆分成小服务之后,各个小服务都运行在自己的进程中,也就是互相隔离微服务之间也需要通信,例如订单服务向商品服务查询一些商品信息,通常使用HTTP API(轻量级机制通信)进行通信。
集群是个物理形态,分布式是个工作方式。
分布式
是指将不同的业务分布在不同的服务器。
集群
指的是将几台服务器集中在一起,实现同一业务。
例如某大型网站用户服务访问量高,那么用户服务就用十台机器一起来运行,我们随便访问哪台都可以,用户服务就是做了集群化处理。
分布式中的每一个服务器,都可以做成集群,而集群并不一定就是分布式的。
用户服务十台服务器运行就是集群,而十台服务器运行的用户服务不能被称为分布式。
节点
:集群中的一个服务器
在分布式系统中,各微服务可能处于不同服务器,但是服务之间不可避免的需要相互调用。
SpringCloud中推荐使用 HTTP+JSON的方式完成远程调用。
分布式系统中,A服务需要调用B服务,B服务在多台服务器中都存在(集群),A调用任意一个服务器均可完成功能。
为了使每一个服务器都不要太忙或者太闲
,我们可以负载均衡的调用每一个服务器,提升网站的健壮性。
常见的负载均衡算法:
A 服务调用 B 服务,A 服务并不知道 B 服务当前在哪几台服务器有,哪些正常的,哪些服务 已经下线。解决这个问题可以引入注册中心。
如果某些服务下线,注册中心可以实时的感知到其他服务的状态,从而避免调用不可用的 服务。
每一个服务最终都有大量的配置,并且每个服务都可能部署在多台服务器上。我们经常需要变更配置,我们可以让每个服务在配置中心获取自己的配置。
配置中心用来集中管理微服务的配置信息
在微服务架构中,微服务之间通过网络进行通信,存在相互依赖,当其中一个服务不可用时,有可能会造成雪崩效应
。要防止这样的情况,必须要有容错机制来保护服务。
服务雪崩:
A服务调用B服务,B服务调用C服务,C服务。。。,假如C服务挂了,那么A、B服务将无法正常运行,此时并发很大的话,更多的请求导致请求积压,请求将都会被阻塞,最终会因为一个服务的不可用导致服务器的资源耗尽,所有服务均不可用,导致整个服务的雪崩现象。
服务熔断
设置服务的超时,当被调用的服务经常失败到达某个阈值,我们可以开 启断路保护机制,后来的请求不再去调用这个服务。本地直接返回默认 的数据
服务降级
整体把控:
在系统压力大,资源紧张的情况下,我们可以将非核心服务降级运行(停机不处理,或者简单处理)
在运维期间,当系统处于高峰期,系统资源紧张,我们可以让非核心业 务降级运行。降级:某些服务不处理,或者简单处理【抛异常、返回 NULL、 调用 Mock 数据、调用 Fallback 处理逻辑】。
在微服务架构中,API Gateway 作为整体架构的重要组件,它抽象了微服务中都需要的公共 功能,同时提供了动态提供路由服务,客户端负载均衡,服务自动熔断,灰度发布,统一认证,限流流控,日志统计等丰富的功能,帮助我们解决很多 API 管理难题。
API网关就像大商场唯一的唯一的一个安检入口,我们从这个入口进来,能放行过来的请求就是后台需要处理的
外网部署:面向用户访问的部署前端项目,可以有手机APP和WEB网站。
内网部署:整个后台的服务集群。
用户是通过使用客户端来完成相应的功能。
todo 有的只是听说过,具体功能用法并不清楚,所以这块在之后的学习中需要补充
微服务 | 名称 | 端口号 | 数据库 |
---|---|---|---|
gulimall-gateway | 网关服务 | 88 | |
gulimall-third-party | 第三方服务 | 30000 | |
gulimall-auth-server | 认证服务 | 20000 | |
gulimall-cart | 购物车服务 | 14000 | |
gulimall-search | 搜索服务 | 13000 | |
gulimall-coupon | 优惠卷服务 | 7000 | gulimall_sms |
gulimall-member | 会员服务 | 8000 | gulimall_ums |
gulimall-order | 订单服务 | 9000 | gulimall_oms |
gulimall-ware | 仓储服务 | 11000 | gulimall_wms |
gulimall-product | 商品服务 | 12000 | gulimall_pms |
备注:
10000端口是百度云的一个服务的端口,跳过
VirtualBox – 6.1.26
Vagrant – 2.2.18
docker-ce(社区版,不要钱)-- 20.10.9
mysql – 5.7
redis – 6.2.6
jdk – 1.8
maven – 3.6.1
node.js – v14.15.1
尚硅谷学习视频B站链接:
https://www.bilibili.com/video/BV1np4y1C7Yf?p=3
我们口腔对美食的感觉来自于三观,
第一是我们舌跟口腔黏膜的味蕾体验,这是味道,
第二种是牙齿咬住的这种牙感,这个牙感可以有扎实感,一般讲咬定什么,咬住什么,这是安全感
第三个很重要的,是我们吞咽,吞咽的这个动作,其实带动我们整个胃肠道,向下蠕动,吞咽使我们大快朵颐的基础,这是获得感
圆桌新春派第2期