正式进入工作岗位之前对精进技术的思考——工程上的最佳实践
Why？
首先要理解为什么要从工程实践的角度思考，常规的培训教程虽然是以项目的形式，但目的是帮助我们学会使用基本的开发工具如何使用，而实际开发过程中如何将各种技术组件有效地组合和应用、如何解决实际的业务问题，则是进一步需要关注的问题。
How？
以原有的点评项目为例进行思考，可以考虑各部分设计的原因，能否优化：
- 消息中间件：思考使用场景，如订单状态更新、用户评价通知等，分析为什么要使用消息中间件，以及如何设计消息的生产、消费和存储。
- 缓存：考虑缓存的使用场景，如热门商品信息缓存、用户会话缓存等，分析如何识别并处理热key，以及缓存的更新和失效策略。
- 数据库设计与优化：审视数据库表的设计是否合理，是否符合业务需求，以及如何通过索引优化、查询优化等手段提升数据库性能。
- 微服务架构：分析拆分是否合理，服务之间的依赖关系是否清晰，服务降级、熔断和负载均衡策略是否有效。
- 服务上线：如何上线，例如灰度发布中的流量染色，如何保证服务的高可用性。
以微服务为例进行思考，考虑从调用和原理到设计决策的转变：
- 之前学习时，重点可能放在了如何调用中间件以及它们的底层原理上。
- 现在需要将重心转移到：在给定业务场景下，为什么要这样设计这些组件。
例如，微服务的负载均衡、服务发现、降级熔断等模块，不仅要清楚它们的作用，更要结合业务场景思考如何拆分微服务，以及制定相应的服务降级、熔断和负载均衡策略。以分布式事务为例，虽然有TCC、二阶段提交等理论方案，但在实际开发中，这些方案的严格实现需要很多条件支持，如数据库的兼容性、业务操作的反向接口等。在实际生产中，接口可能无法完美支持这些理论方案，这时需要考虑其他方法，如对账机制，来保证最终一致性，尤其是在对强一致性要求不高的业务场景中。以对账机制的工程实践为例，可能在实现最终一致性的时间间隔上较长，但其泛用性广且易于实现，设计对账机制需要考虑如何在业务执行频率较低时进行对照，以及如何处理幂等性等问题。
在上述思考过程中，可以借鉴大众点评、美团外卖、饿了么、滴滴等成熟项目的技术文章，了解它们在工程实践中的经验和教训。思路放宽，例如，各大应用基本都有点赞模块，了解它们是如何实现的，筛选出和自己的项目比较贴合的部分深入研究。
例如，大众点评在订单系统分库分表实践中的垂直切分和水平切分策略，以及如何通过Hash切分实现数据的均匀分布和易于扩展的架构。
了解了实践中的技术原理之后，再进一步关注通用方法论的提炼：
第一个是基础架构平台层面。例如，分布式ID发号器（如Leaf）、热Key检测与治理、大文件分布式对象存储（如JFS）等，理解这些通用实践，为自己的项目提供参考和借鉴，提升解决实际问题的能力。
第二个是思想层面。例如，在无法控制仓库报送数据的情况下，通过数据分析确定需要特殊处理的仓库，采用简单粗暴但有效的硬编码方式解决问题。此处提炼的方法论是：当技术手段难以直接解决问题时，可以通过分析实际数据和业务场景，找到变通的非技术性方法来绕过技术难题。
以上为主线任务，接下来是支线任务，即提前了解部门技术栈和业务后，例如云原生相关可以了解：
—-与职场老兵William的对话整理