搜索到
24
篇与
的结果
-
架构的起始——黄金链路 架构的起始——黄金链路2023年底，公司有一个部门的对客系统出现了十分严重的故障，损失严重。当日一系列只听过名字，没见过真人的大佬都出现在机房跟进问题排查的进度。事后，具体的原因仍未完全定位。也因这场故障，开始公司级别的重视架构的重要性。2024年，架构提升就摆到了第一位。“黄金链路”应运而生，其指的是一系列涉及客户的重要交易链路的梳理。对于一个几百套系统在生产运行多年的公司来说，想要端到端的完成梳理，是一份巨大的工程。有幸参与到这份工作内容中，也是艰辛伴随着一些成就感。在正式将组织架构调整到架构运维组后，第一份差事就是负责梳理一个未接触过的系统的黄金链路，编写汇报材料。用时1个多月，120多页的PPT，才算完成一份较为完善的材料进行汇报。在此记录一下这份材料编写过程的一些收获。第一是如何进行工作的安排，由中心架构师牵头组织会议，架构运维组全体参加，由系统原负责人进行黄金链路的描述。描述的顺序是业务进行的顺序，讲述使用到的微服务、中间件、外部系统，系统的风险点、监控点，会议中形成泳道图。并在泳道图的每个节点中注释其涉及的数据库表、redis使用的key、es的索引、外部调用的接口等等。第二是汇报的视角，主要分为系统视角与用户视角。系统视角针对泳道图中每一个节点、远程调用进行分析其可能的故障点、应急方案、可优化的方案。从用户的视角，又从对用户的影响分为3种类型，分别是系统报错、内容差错、体验差。并站在用户视角的反馈，梳理第一时间的应急预案是什么，主打三板斧，第一时间停止继续损失，再考虑精确排查问题的节点可能性。第三是汇报的思路，这是一块软技能，对于一张涉及16个微服务，70+节点，30+系统间调用的泳道图，如何向上汇报，让领导能够清晰了解该链路的重要性、当前业务主要的经过、存在的风险点、后续优化的方案、系统应急的方案完善性。首先对该黄金链路的主要业务进行介绍，通过哪些系统对哪些客户进行了服务，服务的量有多大，体现出该黄金链路的价值。其次展示该链路涉及的0层图、1层图（不严格），以及生产部署的物理视图。接着从概要进入详细的泳道图全览，并介绍泳道图中节点的编码方式。然后按照节点重要性进行分类排序、索引，之后再一个个节点进行详细分析，描述其功能，系统视角分类、用户视角分类，故障场景以及对应的应急方案、是否可添加监控、优化方案等等。接着切换为用户视角再总结不同的用户反馈的处理应急预案。最后再附上链路中涉及的表、接口、关键代码的附件。写这样的材料对我来说，真的挺折磨，因为这是公司第一次做这样的事情，汇报材料的模板，格式，都是做了不知道多少次的反复修改，领导每天都能给出一些指导，好在的确是收获不少。之后，我也直接参与了该系统几次生产问题的排查，例如CPU使用率高等问题。发现经过黄金链路的“折磨”后，对链路上的业务已经大致了解了，在排查过程中，真的可以指着泳道图，问对应的同事，这里的表现好像不大对，是不是出现了什么对应的问题。接下来有时间的话，我还想总结一下最近在做的应急演练。思考一下应急演练在测试环境的模拟，系统间问题的编排。不过也不是什么高大上的东西，可能连灰度都不涉及。后一阶段还要在生产上演练~ -
《疯狂的程序员》读后感 《疯狂的程序员》读后感近日，心血来潮，翻出了三年前还没看完的书，看完了剩下的20%内容，看书的感触与以往差别好大。从前看的是200x年程序员的工作，原始，底层。现在看，却是那个年代野蛮的成长——没有良好的平台，没有成熟的框架，甚至网络都是只有几百kb/s，但是对于技术的热情真的是燃烧不止的火焰，烧穿未知的壁垒。从绝影个人的发展来看，就是技术宅到成熟的工程师，到有野心有行动的创业家的改变。书摘（部分）1记住，女人都是假的，狗才永远不会背叛你，狗是唯一爱你比爱自己还多的东西。”2写程序，还是得跟人打交道，只有跟人，你来我往，才是真正智慧上的交流，无论输赢，这才是最有意思的事情。3有些话说了一次又一次，说实话，我都觉得我们对技术的追求和对CASE负责的心理是被资本家们利用了。所以，要我说，写程序就两种：要么纯粹就是爱好，不计任何回报，就像我们刚学写程序那样；要么就是给自己写程序，为自己挣钱，就像我们现在一样。要是一直给资本家写程序，写到最后，就两个字：痛苦！。”4“人定胜天”的思想真是害死人啊。几千年了，中国人一直信仰孟子的教导，并且为了证明他的正确性而不断努力，结果呢？还是唯物主义一语道破天机：“人的主观能动性受客观条件制约”。5BOSS Liu哈哈大笑：“BOSS，你就慢慢去看吧，有一天，你会发现我这代码是堪称经典的。哈哈。6绝影一边读着BOSS Liu的代码，一边骂，这是他向来读别人程序的习惯，这习惯，也是在周总公司养成的。那时候读别人代码，确实应该骂，写得实在太粗糙了，全局变量到处都是，随时用随时定义。7BOSS Liu 心里也有点痛，他说：“当然，能吃饭是最起码的。又要马儿跑又不给马儿吃草，这是周总他们犯的最大的错误，以后我们一定要小心啊。”8事情都是会变的，好多事情如果一成不变，就永远不会有发展。9猛的想起N年前，那时候BOSS Liu还我自己一起在公司，有一天早上BOSS Liu老早就去了公司，手指头被烟熏得很黄很黄，但脸色比手指头更黄。绝影知道，那一次BOSS Liu为了研究多线程的问题，搞了一个通宵。怎么看待绝影在那个年代，技术还是值钱的，不像现在202x年，开发软件已经是一个培训班可以几个月速成的活计。绝影一手汇编脱壳的技术现在90%以上（估计不止）的程序员是完全不会的。然而即使这样，绝影同样遇到了光有技术，没有投资与推广，没有3G作为基础设施，P2P点播这项当时先进技术CASE创业也是完全无法实行。在绝影创业失败前，游戏外挂让他收入颇丰，这其实也是我年少时所崇拜的。但是，外挂犯法，绝影在现实生活中也是如此，因此进了橘子有好几年。守法还是很重要的。PS读完应该是在2023年8月18日的，那天就写了一部分读后感了，然而2023年9月3日才有空再写，电脑坏了一阵子~很多感觉都消失了。
-
新建复杂工程时引入mybatis-plus注意点 新建复杂工程时引入mybatis-plus注意点有如下的工程结构:/root 根目录 /root/module1 模块1 /root/module2 模块2 /root/module_starter 启动模块（依赖模块1、模块2)记得引入starter我们在module1、module2中会定义mapper、dao等类，所以是需要依赖mybatis-plus相关的注解、类的，例如@TableId等。然后在module_starter中存在启动类，就需要注意：这个模块就需要依赖于mybatis-plus-boot-starter， 不然启动后所有@Mapper均不会生效。记得规范@MapperScan包名范围在项目中，mapper可能存在多个包中，需要注意的是，使用@MapperScan 时，包名不可过于宽泛，例如com.company,过于宽泛的包名会导致Service接口被作为Mapper扫描，最终出现重复Bean导致项目启动失败。@MapperScan 中可以配置多个包名，所以建议可配置的精细一些，以mapper为结尾。
-
class path resource 'xxx.yaml' cannot be opened class path resource 'xxx.yaml' cannot be openedclass path resource [ xxx.yaml]cannot be opened because it dose not exist。类路径下无法打开一个文件，因为它不存在。这是一个存在/src/main/resources/ 目录下的文件，理论上，在maven 打包后能够读到的。但是反复报错。通过运行时debug， 执行System.getProperty("java.class.path")打印类路径，能够明确的看到C:\Users\xxx\xxx\target\classes; C:\xxx\xxx\xxx\xxx\xxx.jar; ...点开到classes 目录下，能够看到application.yml 等都存在，但是自定义的 xxx.yaml 的确不存在。蓦然想起因为流水线要求打包的jar包要在最外层的target下，内部module 的pom.xml是有一定设置的。而哪些文件被打包进来是有限制的：<resources> <resource> <directory>src/main/resources</directory> <inculude>**/*.yml</inculude> <inculude>**/*.xml</inculude> <inculude>**/*.properties</inculude> </resource> </resources>唯独少了yaml,所以相应的补充一个*/.yaml 即可。总结一下就是，遇到问题还是看看具体报错信息，逐步定位，其实不难。
-
个人总结-五年 个人总结-五年真的是不知不觉，已经从一个职场萌新，到现在过了有5年了。在过去的一年里，人生观、价值观也都发生了一些小小的改变。原因有多重的，不过毫无疑问，我处在了职场疲惫期。技术进步过去的一年里，似乎也没学什么新的技术，似乎学了什么也用不上。倒是在不断的功能设计评审、系统架构设计中，慢慢对软件有了更深的理解。不过这种内功的进步，没有明确的刻度线，也缺乏可以碰一碰的朋友，是一个难以考究的问题。工作态度的变化想必是前些年透支的工作方式，身体的亚健康问题逐渐透露出来，是需要好好重视的。在体检之后，都是担心好几周，想必朋友们也会有这样的感觉吧。这也是主动放下技术的学习进度、工作的拼搏程度，把更多的时间交还给自己进行“浪费”的原因。如果不想把赚来的微薄薪资再通过医院上交，建议各位也要重视身体，健康为祖国工作50年。工作必须按照项目计划完成！！！ —— 这一原先十分看重的事，在经历多了之后，也是感觉不那么重要了，不乏有些人故意将dead line 提前几天再告知到你。自己把握感觉是长久之道。技术or管理？相信很多人都会面临这样的抉择！领导会在工作中尝试将项目经理，抑或是其他带有一些管理属性的工作交由你来完成，以此来测试你是否有管理才能和天赋。这里就有两种情况，热爱技术，愿意一直处于一线的技术爱好者，以及抓住机会就想要往管理转型的人。技术和管理，在我眼里没有优劣，而是各有长短。技术是一个“铁饭碗”，在当前行业未进入夕阳阶段时，混口饭吃不太成问题，做的优秀是可以大放异彩的，而且个人成就感也是层层递进的。管理是一个综合能力的岗位，起码要有千人千面，见人说人话，见鬼说鬼话的觉悟。非顶层领导的话，较多功能就是发挥承上启下，润滑油的作用。一定程度上，会需要更全面地去了解公司、条线中的业务。需要有个人去思考下一步做什么的想法。个人感觉管理一事，更为烦琐。我自认为是一个耐心有限的人，喜欢和聪明的人说话。而管理需要耐心，即使面对石头也要有点化其的耐心咯。管理还有个缺点，就是稍微有点绑定在这家公司。若是技术转管理后，未保持技术的进步，个人又无太强的领导人格魅力，完全就是个轴承的话，就将面临一个被釜底抽薪的问题，腿不是你的，口不是你的，上层发动多少的速率，你只能被动接着，着实会心累。管理比较明显的就是交际面、薪资会比底层工作者更加open一些。如何选择之后的路首先，如何选择只在于自己，他人的只是意见，不是决策。在过去的一两年里，由于性格的问题，我可以说用行动上进行拒绝了两次这样的实践机会。承蒙不弃，今年我想尝试一下，用半年多的时间压制急躁的性格，磨练一下自己。做出这样的选择，并不是被他人的想法裹胁，而是尝试跳出自己的舒适圈，让自己在职场的疲惫期中，稍做一些改变，带来一些新的气息。接下来一年的事接下来的一年中，首先全力备考软考-系统架构师，去年仅上午差3分很是可惜。副高的职称肯定会有用上的机会。再去一些管理相关的书籍，我希望，我能够有点点领导人格魅力吧，不要成为我最鄙视的样子。然后该读闲书还是要读，稳定情绪。加油！！！
