搜索到
9
篇与
的结果
-
随笔-第一次接触DDD与微服务 随笔-第一次接触DDD与微服务 首先，感谢公司提供这次学习DDD（领域驱动设计）的机会。 经过上次雷老师的讲解，这两个月来，我对微服务架构有了整体的了解，并持续关注了雷老师的项目。结合这次培训和个人理解，我总结了以下几点： 微服务架构的核心要素 微服务架构主要包括： 基础设施（原中间件）：Redis（缓存管理）、Kafka（消息队列）、Consul/Eureka（服务注册）、Elasticsearch（搜索引擎）等。 DDD（领域驱动设计）：重点在于领域建模和界限上下文的划分。 数据库：微服务架构下的数据管理策略，包括分库分表、分布式事务等。 Docker：环境容器化，让环境像代码一样可定义、可声明，提升部署效率。 其中，对我来说最陌生但最重要的部分是基础设施，这次培训重点讲解了如何将基础设施与DDD整合，并提供了基本的DEMO示例。 领域驱动设计（DDD）理解 传统软件设计通常围绕数据库进行架构，而DDD则是围绕领域和界限上下文进行业务扩展。 领域及子域 以我们公司所处的服装行业为例，面料平台就是一个领域，而它可以进一步拆分为多个子域： 交易中心（核心域） 运营中心 商家管理 扫描仪 不同子域之间存在层级关系，例如：交易中心与商家管理之间是上下级关系。 界限上下文 以交易平台为例，它的界限上下文包括： 面料管理（面料列表、搜索、详情） 面料对比（加入对比、对比分析、取消对比） 用户管理（个人用户） 实体、值对象、聚合 实体：具有唯一标识，例如“用户”。 值对象：数据不可变、无唯一标识，例如“用户地址”。 聚合：封装了实体、值对象和仓储，并通过服务暴露出去。 工厂模式 工厂用于创建和管理复杂对象，确保领域对象的一致性。 DDD 与微服务的整合 在微服务架构中，Spring Cloud 通过封装 Redis、Kafka、Consul 等基础设施，使其能够以注解和配置的方式无缝集成项目。这些组件如同武器，而DDD是一个武林高手，关键在于如何合理运用。 此外，Spring Boot 通过注解取代 XML 配置，实现“约定优于配置”，简化开发流程，符合当前行业趋势。 微服务架构落地的关键问题 1. 服务化后的管理 JAR 包如何管理？是每个包一个 Docker 镜像，还是一个界限上下文一个镜像？ 端口、日志等规范化管理。 2. Docker 仓库管理 如何高效存储和管理微服务镜像，减少重复构建和拉取。 3. 安全性 可以采用 OAuth + Shiro 结合 Zuul 路由 来控制权限。 4. CI/CD（持续集成 & 持续部署） 如何使用 Jenkins 实现自动化部署，减少人工干预，提高效率。 5. 版本号管理 采用 Maven + Git 进行版本控制，避免人工打版本号。 JAR 包管理策略，避免版本混乱。 6. 单体架构向微服务迁移的思考 为什么要迁移？微服务是否适合当前企业需求？ 迁移前的技术债偿还、新架构设计原则、团队变革等准备工作。 迁移过程中需要遵循的设计规范。 分布式事务一致性：虽然雷老师建议使用 TSDB 而非传统事务，但目前对其原理仍有疑问，需要进一步研究。 中间件选型：如何选择合适的消息队列、数据库、缓存方案等。 如何让其他职能团队平滑切入？（UI、产品、运维、测试、前端等） 结语 微服务架构的落地涉及众多技术和管理挑战，这次培训让我对DDD有了更深入的理解，同时也意识到微服务架构实施过程中仍有许多待解决的问题，需要进一步探索和实践。 雷老师的github地址：https://github.com/linux-china -
随手记-为了保证实时一致需要使用强制事务 随手记-为了保证实时一致需要使用强制事务 事务相关原则 强制事务保证实时一致：为确保数据在任何时刻的一致性，对于一些关键场景需要使用强制事务来保障数据的实时准确性。 互联网强调最终一致：在互联网环境中，允许业务线在时间轴上的某个阶段数据和动作存在不一致情况，但最终必须保证数据的一致性。 第三方交互的消息机制：当与第三方系统进行交互时，务必采用消息机制作为中间层，以避免第三方系统的问题导致自身系统被拖垮。 消息中间件应用场景 大数据量请求扩展：主要用于减少系统中重要业务的压力，可处理大数据量请求。不过并非所有请求都适合用消息中间件异步处理，对于像ajax的主要业务且需要实时更新数据的情况，仍需采用同步方式。 特殊消息类型： 顺序消息：在一些业务场景中，如订单下单后通知出库信息，若消息顺序错误，可能导致报表统计数据不一致，所以需要保证消息顺序。同时存在后发消息先被消费的可能，因此要处理好顺序消息。 定时消息：按照设定的时间进行消息发送。 重复消息：当消费者未响应时，投递者会重复投递消息，例如气象系统通知消息。且要保证消息的幂等性，即无论消息投递多少次，都不会影响请求或数据的一致性，如订单通知始终只对应一条订单操作。 高并发场景：例如直播业务中更新粉丝数的操作，可利用消息中间件应对高并发情况。 消息中间件对比 RabbitMQ：其特点是放弃一定的吞吐量来保证数据一致性，当达到一定吞吐量时，可能需要进行特定的定制。 RocketMQ：目前已不再进行维护。 KafkaMQ：具有高吞吐量，但数据一致性表现不佳，存在数据丢失的风险。 DRDs（分布式关系型数据库服务） DRDs通过member_id来定位数据库，用于分布式数据库的管理和数据定位。 TXC（Taobao Transaction Construction） 数据库事务业务场景：由于单库存储在容量和性能上存在限制，TXC可用于解决分布式数据库事务相关问题，以满足业务需求。 分布式session处理：在分布式系统中，需要将session存放在redis中，以保证在不同节点间session的共享和一致性。 下订单业务示例 操作消耗差异：下订单操作中，insert操作消耗相对较低，而update操作消耗较高。在高并发情况下，为避免性能瓶颈，需要将update等操作进行异步化处理。 消息中间件与事务：消息中间件无法保证消息一定能发送成功，且本身不支持事务。但在分布式系统中，可通过半事务机制实现最终一致性。 半事务理解： 第一次理解：客户端以分布式、高并发的方式发送消息给消息中间件，而消费者（服务端）在消费消息时必须遵循事务规则（此理解可能存在错误）。 第二次理解：对于分布式事务，假设有两个存在先后顺序的事务，如事务1为消费10，事务2为增加10。通过消息中间件处理，事务1的消息发送给消息中间件后，消费者可消费事务1，但事务2必须在事务1执行完成后才能启动。 消费顺序：以双十一的下订单、付款、扣款流程为例，消费者必须按照事务的执行顺序，先消费下订单消息并提示用户下订单成功，接着处理付款消息并提示付款成功，最后进行扣款操作。按照这样的顺序逐步实现业务逻辑，以保证业务流程的正确和数据的一致性。
-
大话程序猿眼里的高并发 大话程序猿眼里的高并发 简单理解高并发 高并发指的是在同一时间点，有很多用户同时访问某个URL地址。例如淘宝的双11、双12活动，贴吧的爆吧事件（恶意的高并发请求，即DDOS攻击）。简单来说，就像玩游戏中被ADC暴击了一样，伤害巨大。 高并发带来的后果 服务端：站点服务器/DB服务器资源被占满崩溃，数据存储和更新结果与理想设计不一致（如重复的数据记录，多次添加用户积分等）。 用户角度：页面卡顿，用户体验差，可能导致用户流失。 我的经历：在开发公司产品网站时，经常会有类似抽奖、签到、积分竞拍等功能需求。如果未考虑高并发下的数据处理，可能会导致数据异常，影响用户体验。 实例分析 并发下的数据处理 通过表设计（如记录表添加唯一约束）、使用事务防止并发下的数据错乱问题，以及通过服务端锁进程防止并发下的数据错乱问题。 例子1：签到功能 需求：一天一个用户只能签到一次，签到成功后用户获取一个积分。 已知表：用户表，包含积分字段。 设计： 添加一张签到记录表，并将用户唯一标识字段（ID, Token）和签到日期字段设为唯一约束或索引。 在代码逻辑中，先执行签到数据的添加，再进行积分的添加。 所有操作写在一个SQL事务里，确保数据一致性。 例子2：抽奖功能 需求：抽奖一次消耗一个积分，抽奖中奖后编辑剩余奖品总数。当剩余奖品总数为0或用户积分为0时无法进行抽奖。 已知表：用户表（包含积分字段），奖品表（包含奖品剩余数量字段）。 设计： 在事务中，通过WITH (UPDLOCK)锁住商品表，或更新表的奖品剩余数量和最后编辑时间字段来锁定数据行。 进行用户积分的消耗，完成后提交事务，失败则回滚。 例子3：缓存数据到Cache 需求：当缓存不存在时从数据库获取并保存到缓存中；每天10点必须更新一次，其他时间点缓存两小时更新一次。 问题：10点时有很多并发请求同时过来，导致大量SQL查询操作，增加服务器压力。 解决：C#通过lock机制，在从数据库读取到缓存的代码前加上锁，确保只有一个请求是从数据库获取数据，其他都从缓存中获取。 访问量大的数据统计接口 需求：用户行为数据统计接口，记录商品展示次数等。 问题：大量用户同时在线访问页面会导致大量请求，给服务器带来巨大压力。 解决：通过Node.js写一个数据处理接口，把统计数据先存到Redis的list里，然后再同步到MySQL数据库中。这样可以减少数据库压力，加快响应速度。 高并发下的服务器压力均衡 服务器代理Nginx：做服务器的负载均衡，分散压力到多台服务器。 集群部署：MySQL数据库、Redis服务器或MongoDB服务器，常用查询数据保存到NoSQL DB中，减少数据库压力。 数据缓存：使用Cache。 编程语言选择：使用具有高并发能力的语言（如Node.js）开发Web接口。 服务器部署：图片服务器分离，静态文件走CDN。 数据库优化：优化查询条件和索引。 消息队列：将数据添加到信息队列（如Redis list）中，再写工具入库。 脚本控制请求：防止用户重复点击导致多余的AJAX请求。 并发测试神器推荐 Apache JMeter Microsoft Web Application Stress Tool Visual Studio 性能负载 文章来源
-
