无论你从事什么行业，首先要对市场有概念。你选择了一个行业，首先要去想怎么切入市场。对于计算机行业而言，市场被大公司所占据，对于个人而言，切入市场的方式就是迎合这些公司的招聘要求，这相当于从被动的角度去解决问题。但是如果你有自己的爱好，对这个爱好能保持长期的热情，并且这个爱好也可以切入市场，这时候，你可以选择去迎合大公司，但是同样，你也可以从社会的供需关系来切入市场，从最底层来塑造一个模式，利用复利的原理来扩大这个模式。这个模式，很可能不是技术书、面试题所能衡量的，它可能并不是高科技，也不漂亮，但是你的目的是让它增长，然后再复制这个模式。如果你的兴趣就在这里，那你就仔细思考思考这个社会的经济形势和人与人之间的利益关系，想明白之后，塑造你的产品，为别人创造价值。慢慢你会发现，你自己有一个小圈子，在这个圈子里，你了解其中的一切，你明白游戏规则，这里的一切你做主。相反，如果你只知道学技术，刷题，即便你的技术再好，内心深处仍然会有被别人支配的恐惧感。而且，你时常会疑问，技术到底学多少，才能没有恐惧感？答案是，越学技术，很可能你会越质疑自己。因为你在一个无比复杂的圈子里，但是很难塑造自己的圈子，就是那个你自己做主的圈子。
CloudOps是传统IT运维和DevOps的延展，通过云原生架构实现运维的再进化，充分帮助企业降低IT运维成本、提升交付速度和系统灵活敏捷度、增强系统可靠性，构建更加安全可信开放的业务平台。
https://developer.aliyun.com/article/833488
这个世界是不公平的，你活得越久，站得越高，看得越清，你就越会意识到，世界的本质其实就是不公平。所以所有的宗教、法律都在追求公平，追求公平恰恰说明，世界是不公平的。
摘抄：《拆掉思维里的墙》
PropertyEditor：Spring 框架的属性编辑器接口，将不同类型转换为JVM内部对应类型。（按照这种理解，实际上是一个类型转换器）
文档：https://springdoc.cn/spring/core.html#beans-beans-conversion
商业化的第一责任人：产品经理 or 销售？
第一种情况：Sales负责，这种情况下，销售负责人会大量拜访客户，而产品经理负责陪访、负责接需求。为了签前几个客户，销售同学不得不答应为客户做很多功能。这样做的结果是，我们会做出和市场上竞品很像的产品。
第二种情况：共同负责—— 产品的事情产品经理负责、销售的事情Sales负责。Sales在外面见客户，把需求带回来给产品经理；产品经理就是接需求的，在家自己拍脑子判断；最后每次发版后发现新版本根本不符合客户的需要。也有产品经理陪同Sales拜访客户频率很高，但如果没有明确的商业化责任人，不善言辞的产研同学与强势的销售同学往往不能达到良好协同：
要么是产品同学无条件让步，产品丧失前后一致的价值逻辑
要么是双方互相无法说服——到底是直接做这个客户要求的功能，还是设法引导客户采用业内更有效率的“最佳实践”？
第三种情况，由产品经理负责（推荐），只有这个产品的PM（Product Manager，产品经理）才有机会真正看清诸多客户要求背后的真正的需求、安排好各个功能上线的先后顺序，以及在产品设计、开发、测试、实施、服务各方面的资源分配。大家会有质疑：产品经理商务能力不行，签不到单子如何商业化？—— 其实不用“商务能力”签到的单子，才是质量更好的单子。早期能否找到的几个“对的”客户，决定了产品能否少走弯路。我带过规模很大的销售团队，所以见过大量签“错”的单子。Sales承诺了无法实现的价值、客户被我们Sales的执着打动而买单、客户看到产品宣传没考虑自身情况就冲动购买......这些都不是“对的”客户。此外，也可以找有业务管理能力的销售管理者辅助商业化负责人。但谁为主、谁为副，应该非常清晰。
对商业化负责人的要求：
热情、高投入和坚定
对目标客户的业务有深刻理解
有做SaaS产品的套路
善于独立思考
领导力
首先，热情靠激发。
其次，CEO们往往会纠结：应该找一个懂客户业务的，还是懂产品套路的人？我认为行业背景、对客户业务有深度理解和独特思考会更重要。产品套路可以学习、营销经验可以短期培养，但对目标客户业务的认知却是需要5年、8年的浸润才能形成的。商业化负责人可能每天都需要做几个、甚至十几个决策，如果Ta不能理解公司给出的抽象目标，往往就会跑偏。
第三，业务第一，管理为业务服务。所以管理能力在这个阶段也不是最重要的。但毕竟商业化需要一个小团队，负责人的领导力是必须具备的。小团队Leader的领导力也不复杂，简单讲就是：客观公正+勤于沟通，并不要求长袖善舞，能把大家团结起来为一个目标努力。
微服务带来的新问题：
自动化
可观测性：日志（ELK）、跟踪（Skywalking）、指标（Prometheus）
分布式问题：分布式事务、数据关联、幂等性
SOA与微服务：
SOA：整合不同异构系统，ESB 统一解决；基于配置
微服务：拆分系统，分而治之；约定大于配置
DDD：
DDD：指定微服务划分，方法论，熟悉业务再建模；统一语言（业务、技术），化繁为简