渔阳的博客

SpringCloudAlibaba GitHub地址：https://github.com/alibaba/spring-cloud-alibaba/中文网站对应的地址：https://github.com/alibaba/spring-cloud-alibaba/blob/master/README-zh.md注册中心：Nacos配置中心：Nacos负载均衡：Ribbon声明式服务调用：OpenFegin服务容错：Sentinel网关服务：Gateway链路监控：Sleuth。

单体架构应该是最先接触到的架构实现了，在单体架构中使用经典的三层模型，即表现层，业务逻辑层和数据访问层。单体架构只适合在应用初期，且访问量比较下的情况下使用，优点是性价比很高，开发速度快，成本低，但缺点也很明显，这时扩展的首先就是考虑服务器的集群处理。

需求，组件0 改变了数据，其它组件也想获得改变后的数据，如图所示这种多个组件之间要共享状态数据，useState 就不够用了，useContext 也不好用了能够和 react 配合使用的状态管理库有MobXRedux其中 Redux API非常难以使用，这里选择了更加符合人类习惯的 MobX，它虽然采用了面向对象的语法，但也能和函数式的代码很好地结合。

【代码】全局异常处理类。

首先要保证资料齐全下载代码，并运行，评估注释如何，查看代码规范代码不一定能完整看出项目打开对应文档文档不明了,直接打开可以访问的地方，看看需求最好还是运行一下。

无状态：对单次请求的处理，不依赖其他请求。先解决核心的问题，预测未来可能出现的问题。第二次请求依赖第一次请求这就是有状态的。对现有问题有方案，对未来系统有预案。不要过度复杂化系统。

若Producer本地事务执行成功则自动向MQ Server发送commit消息，MQ Server接收到commit消息后将消费消息，消费成功则向MQ回应ack，否则将重复接收消息。在RocketMQ 4.3后实现了完整的事务消息，实际上其实是对本地消息表的一个封装，将本地消息表移动到了MQ内部，解决Producer端的消息发送与本地事务执行的原子性问题。以上主干流程已由RocketMQ实现，只需要分别实现本地事务执行以及本地事务回查方法，因此只需关注本地事务的执行状态即可。这就涉及到到了分布式事务，

把使用单机 MySQL 的系统升级为读写分离的多实例架构非常容易，一般不需要修改系统的业务逻辑，只需要简单修改 DAO (Data Access Object,一般指应用程序中负责访问数据库的抽象层)层的代码,把对数据库的读写请求分开，请求不同的 MySQL 实例就可以了。，使用分离组件的方式。除了访问 MySQL 的并发问题，还要解决海量数据的问题，很多的时候，会使用分布式的存储集群，因为 MySQI 本质上是一个单机数据库，所以很多场景下，其并不适合存储 TB 级别以上的数据。

为OAuth2.0的资源服务器角色，实现接入客户端权限拦截、令牌解析并转发当前登录用户信息给微。-keystore D:/jwt/jwt.jks(指定生成证书的位置和证书名称)（2）将用户信息存储进当前线程上下文（有利于后续业务逻辑随时获取当前用户信息）//4. 校验通过后，从token中获取的用户登录信息存储到请求头中。（2）令牌解析并转发当前登录用户信息（明文token）给微服务。// 拿到token后，通过公钥（需要从授权服务获取公钥）校验。//1.过滤不需要认证的url,比如/oauth/**

UUID(Universally Unique Identifier)的标准型式包含 32 个 16 进制数字，以连字号分为五段，形式为 8-4-4-4-12 的 36 个字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有 5 种方式生成UUID，详情见 IETF 发布的 UUID 规范 A Universally Unique IDentifier (UUID) URNNamespace。

每当指针走到该任务对应的数据节点上时，remainingRounds就减少1，直到remainingRounds为0时，就触发当前定时任务。从这个原理中可以看到，tickDuration越小，定时任务就越精确，但是响应的，系统的计算负担就越重。实现定时任务的框架有很多，目前在国内用得比较多的是elasticjob和xxljob。在这个实现中，访问的目标地址target，是作为任务参数传入的。在配置每一个部分的表达式时，可以指定具体的数值，比如分钟位设置为0，表示每次第0分钟执行一。缺点：只能在本机上执行；

【代码】电商项目part02 电商后台多数据源。

首先,电商系统面向的角色是:用户、运营人员和管理者。这三个角色对电商系统的需求是:用户通过系统来购物,运营人员负责商品的销售,管理者关注系统中的经营数据。电商系统最核心的流程是用户购物的流程,购物流程从用户浏览选购商品开始,加购、下单、支付、运营人员发货、用户确认收货,至此电商系统的购物流程结束。细化这个流程之后,我们可以分析出支撑这个流程的核心功能模块:商品、订单、购物车、支付和库存。除此之外,一个完整的电商系统还包括促销、用户、账户、搜索推荐和报表这些必备的功能模块。