电商微服务

整体逻辑

一个电商项目通常会包括以下几个功能模块，这些模块可以使用各种不同的技术来实现。以下是一些常见的功能和对应的技术选型：

1 用户注册和身份验证：用于用户注册和登录的功能。可以使用OAuth，JWT，或者自定义的身份验证系统。对应的技术可以是Spring Security（Java），Passport.js（Node.js）等。

2 商品浏览：这是电商网站的核心功能，用户可以浏览并搜索商品。这可以使用Elasticsearch来提高搜索的效率。

3 购物车：允许用户保存他们想购买的商品。Redis（一个内存数据库）是一个不错的选择，因为购物车的数据通常需要频繁读取和写入。

4 订单处理：处理用户的购买请求，生成订单。这部分可能涉及到复杂的业务逻辑，通常会使用一些后端开发框架，如Spring Boot（Java），Express.js（Node.js）等。

5 支付：处理支付和退款。可以使用第三方支付服务，如PayPal，Stripe等。

6 通知服务：向用户发送订单更新或营销信息。可以使用邮件服务提供商如SendGrid，或者短信服务提供商如Twilio。

7 评价系统：让用户对购买的商品进行评价。可以使用关系数据库如MySQL，PostgreSQL等来存储用户的评价。

8 客户服务：处理用户的问题和反馈。可以使用CRM系统，如Salesforce等。

9 数据分析：对用户行为和销售数据进行分析。可以使用数据仓库如Google BigQuery，或者数据可视化工具如Tableau。

Kafka 和 RocketMQ 都是分布式消息系统，可以在一个大规模电商应用中扮演很重要的角色。他们可以用于以下功能：

1 事件驱动架构和微服务通信：在微服务架构中，服务之间需要相互通信，消息队列（如 Kafka 和 RocketMQ）是实现这种通信的一种有效方式。例如，当用户下订单时，可以把这个事件发送到消息队列中，然后有其他服务（如库存管理服务，物流服务等）监听这个队列，并作出相应的操作。

2 异步处理：电商应用中有很多需要长时间处理的任务（如生成报告，发送大量的邮件等）。这些任务可以放到消息队列中异步处理，从而不会阻塞用户的请求。

3 日志和监控：Kafka 可以用来收集和处理来自各个服务的日志。通过这些日志，可以进行系统监控，异常检测，以及业务分析等。

4 流处理和实时分析：Kafka 有一个名为 Kafka Streams 的组件，可以用来进行实时的流处理。例如，可以实时统计用户的购买行为，从而得到实时的销售数据。

5 解耦和扩展性：通过使用 Kafka 或 RocketMQ，可以让系统的各个部分解耦，更容易进行扩展。

对于具体选择 Kafka 还是 RocketMQ，需要根据具体的需求和团队的技术能力来考虑。两者都是非常成熟和强大的系统，但也有一些不同的特点。例如，Kafka 更适合于需要大量数据处理和实时分析的场景，而 RocketMQ 则在保证消息的顺序性和事务性方面表现更优。

1、user service

 1）BaseModel struct
 User struct(继承 BaseModel)
 2）定义完数据连接表 mysql
 3) 用户passwd md5盐值加密（明文正着encode到数据库，即使有了盐值和彩虹表也无法反向解出来）
 4）完成后续接口先要完成proto接口定义
 user.proto  增删改查用户

2、对外提供api — user web

grpc到http需要gateway 或 gin，而gin要更灵活一些

1）go zap 日志库 --- 主打高性能
运行中就可以打印 “启动服务器，端口是多少“等等，代替console.log ，还能写到文件中
为了多人访问全局变量安全，加锁，而zap.S()已经帮咱们做了
2）能把日志输出到文件中
3）gin--作为router用，就是一个个地址
这里面获取用户列表就要用grpc了，通过ip端口连接用户服务

3、viper 配置文件管理库

1、解析xxx.yaml里面的变量

4、登陆注册

在这里插入代码片

5、服务

缺点
  1）两个服务的时候，A服务可以通过配置文件中的ip:port 访问到B服务
但是成百个服务也这么搞嘛？互相调用这样搞不会很乱嘛？
每个服务中都会维护大量的配置信息，而且新加服务的话，相关联的服务都要添加配置文件信息
  2）并发过高---加机器解决，一台机器ip就会变，所有服务都要修改配置文件

1、基于配置文件过多的弊端--通过注册中心来解决
不管是新加服务还是机器，将ip:port 注册到注册中心统一管理
拉取配置信息也都统一去注册中心拉取
2、注册中心功能--注册，拉取（服务发现），健康检查（定期检测服务是否是通的），能不能分布式，能不能一致，稳定
支持网关
3、gateway---浏览器是通过网关来访问微服务中心的

技术选型

1、zookeeper---Java写的
2、consul,etcd---go
consul 具有dns功能
如果在windows/system32/etc/drive/hosts 里面写了，那么host就解析域名返回ip了，不用dns了

1、添加/删除功能就是发一个put的http请求
代码中调consul/api的包就行了
2、同一个服务注册多个实例就涉及到负载均衡
3、gin要将自己的服务注册到consul当中，通过consul发现底层的微服务，
4、grpc 健康检查---grpc自己预留了proto的健康检查接口 grpc.health.v1 调这个接口就行了

6、负载均衡

1、consul统一管理端口的，
  开发环境的时候端口不能频繁改动，线上环境的时候是consul动态分配的
2、微服务可以用各种语言写
3、nignx主要针对http，不是grpc
4、负载均衡就是解决多台机器的时候它来决定哪台来响应的问题
5、LVS,HAproxy,nginx都是负载均衡器

1、集中式负载均衡--单独机器，那台用于负载均衡的机器将成为性能瓶颈
2、进程内负载均衡--将LB的功能和算法以sdk的方式实现在客户端进程内， 缺点一种语言一套sdk
3、独立进程LB(load balance)--与第二种方案不同之处是，它将LB和服务发现功能从进程内移出来，
变成独立的进程，host上的一个或多个服务要访问目标服务时，都通过同一主机独立的LB进程做服务发现和
负载均衡。
缺点等于说多维护一个进程

下图为进程内负载均衡，也是主流方案

下图为集中式LB方案，首先服务的消费方和提供方不直接耦合，而是之间有一个独立的LB(LB通常是专门的硬件设备F5，或者基于软件如LVS,HAproxy等实现)

下图为独立进程LB

LB算法