Everything you care about in one place
Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.
Get Feederwechat2rss.bestblogs.dev
架构师之路
Get the latest updates from 架构师之路 directly as they happen.
Follow now < 10 followers
Latest posts
Last updated 18 days ago
微信为什么做不到，群消息的时序一致性？（第91讲，收藏）
19 days ago
原创 58沈剑 2025-08-29 08:16 北京 架构师之路：架构设计中的100个知识点（91） 《架构师之路：架构设计中的100个知识点》91.消息时序一致性很多业务都需要考虑消息投递的顺序性：1. 单聊消息投递，保证发送方发送顺序与接收方展现顺序一致；2. 群聊消息投递，保证所有接收方展现顺序一致；3. 充值支付消息，保证同一个用户发起的请求在服务端执行序列一致；消息顺序性是分布式系统架构设计中非常难的问题，有什么常见优化实践呢？折衷一：以客户端或者服务端的时序为准。不管什么情况，都需要一个标尺来衡量时序的先后顺序，可以根据业务场景，以客户端或者服务端的时间为准，例如：1. 邮件展示顺序，其实是以客户端发送时间为准的；画外音：发送方只要将邮件协议里的时间调整为1970年或者2970年，就可以在接收方收到邮件后一直“置顶”或者“置底”。2. ???杀活动时间判断，肯定得以服务器的时间为准，不可能让客户端修改本地时间，就能够提前秒杀；折衷二：服务端生成单调递增id作为时序依据。对于严格时序的业务场景，可以利用单点写db的seq/auto_inc_id生成单调递增的id，来保证顺序性。画外音：这个生成id的单点容易成为瓶颈。折衷三：假如业务能接受误差不大的趋势递增id。消息发送、帖子发布时间、甚至秒杀时间都没有这么精准时序的要求：1....
究竟什么是架构设计？（第1讲）
20 days ago
2025-08-28 13:04 北京 《架构师之路：架构设计中的100个知识点》 1.究竟什么是架构设计？ #程序员 ##架构师 #架构师之路 #干货分享 合集1：架构师之路：流量从10万到10亿，一定会遇到的80个架构问题（8000字长文） 合集2：关于即时通讯架构的一切！ 究竟什么是架构设计？（第1讲）...
Google：BigTable究竟要解决什么问题？（第90讲，收藏）
21 days ago
原创 58沈剑 2025-08-27 08:15 北京 架构师之路：架构设计中的100个知识点（90） 《架构师之路：架构设计中的100个知识点》90.Google BigTable前几篇聊了Google三驾马车中的：《GFS经典架构设计（第84讲）》《MapReduce经典架构设计（第85讲）》很多朋友让我聊聊第三部分，Google BigTable。BigTable，很多人对它耳熟能详，但其工程架构并没有什么巨大的创新，今天和大家聊聊，Google为什么要发明BigTable，它究竟要解决什么问题呢？什么是BigTable？Google BigTable是一个分布式，结构化数据的存储系统，它用来存储海量数据。该系统用来满足“大数据量、高吞吐量、快速响应”等不同应用场景下的存储需求。画外音：本质上，BigTable是一个存储系统。有BigTable之前，Google面临什么问题？Google并不是一群人坐在办公室开会，想出来的系统，Google面临着很实际的业务问题。画外音：有些公司的基础架构部，是坐在办公室开会，想出来的东西，然后强推业务线使用。典型场景一：网页存储Google每天要抓取很多网页：1. 新出现的网页，新URL；2. 旧网页，旧URL；对一个已抓取的网页，旧URL为啥要反复抓取？因为，网页会更新，例如新浪首页：sina.com.cn/index.htmlURL虽然没有变，但依然会抓取。画外音：我去，相当于，被抓取的URL集合，只会无限增大，趋近无穷。这里，对于存储系统的需求，是要存储：不同URL，不同时间Time，的内容Content。画外音：URL+”Content”+Time...
大厂大批量裁掉中年员工，到底对不对?
21 days ago
58沈剑 2025-08-26 20:35 北京 这真的正确吗？ 他们和我说大厂裁员是正确的、科学的、必要的、是内部人员结构优化，是打工人自己没本事所以只能被裁。我听了之后很难过，我觉得我们的同胞不该像甘蔗一样被人吸食干净之后就随意的扔掉，尽管这种现象确实普遍存在的，但这真的正确吗？我也想请教一下被裁的人员，你们对于被裁是心甘情愿的吗，你们认为这种行为是正确的吗？主题：大厂大批量裁掉中年员工是正确的吗?https://www.zhihu.com/question/532642791【回答1】结论正确，理由错误。裁员不是因为打工人自己没本事，而是打工人在短期利益面前选择了错误的行业。这些大厂，其实只是单指互联网大厂，其他行业的大厂都没有在裁员，更不会裁中年员工。互联网大厂的发展是在过去十五年里，资本结合买办，利用国内反垄断缺失、外资监管缺失、数据安全管理缺失三合一造成的幻觉，在经济增长放缓、数字隐私启蒙、数字领土强化的过程中，都已经在裸泳，整个行业快速下行。资本红利溢出，抢人才，抢赛道，低能高包的时代已经不复返了，打工人如果能认清自己的真实价值，互联网外的各行各业都一直有信息化的岗位需求。【回答2】正确或者不正确，其实也不重要。使用落后的管理方式，搞落后的生产关系，反正也是会被淘汰的，不用替资本家着急，打工人也没法教他们做事。实践是检验真理的唯一标准，这对企业，对打工人，都是一样的。来点实在的话，择业要看清楚、想清楚，一定要对企业做背调，了解他们的做事方式和管理逻辑，不合适的话，就尽量不要加入。如果说进了一个企业，有一些困难，但你能生存下来，你还能给企业创造一些clarity，能够deliver价值，那么你的报酬大概率是会到位的。你能处理多复杂的局面，你就能拿多高的工资。粗俗一点讲，能吃多少屎，就能赚多少钞票。处处依赖环境好才能工作的，只能是初阶岗位。在头部行业，竞争激烈，能胜任初阶岗位的人很多，如果不持续发展的话，初阶的位置当然是坐不稳的，这是没办法的事情。就像企业可能被市场淘汰，打工人也会被淘汰，这是市场规律。今天我们的生产力还无法支持对每个人都提供很好的社会保障，或者，永远也支持不了。【回答3】裁中年员工不是手段，是结果。大厂大部分人拼的是体力，不是经验。中年人体力逐渐下降，经验却并没有比之前有明显的提升。因此当环境下行时，中年人就成了最早被优化掉的人。相较于传统行业，互联网的特点是敏捷与创新，而非可靠与经验。再加上资本加持，大厂们纷纷把科技行业做成了劳动密集型行业，如果把业务比作万米长跑，大厂们竞争的方式是人海接力，接棒就是加速跑，掉速就换棒。残忍的是当你有一天跑不动了，掉速了，一些不负责任的老板会指着那些依然跑得很快的人告诉你，你不够努力或者你能力不行。你和这些优秀员工的PK叫赛马，跑得最拼最快的人叫卷王，老板那套看似公平，但其实有悖人性的理论是PUA，比PUA更体面的劝退方式是薪酬倒挂。互联网赶的是时间，也愿意花钱买时间，却不大愿意培养人。当有一天环境不好钱少了就不愿意再买那些收益变少的时间了。而对于个人，年轻时最值钱的就是时间，要想好交换的对象，体力与潜力要平衡，用时间换经验。【回答4】8年程序员工作经验：大中小厂都待过，裁员无非就是效益不好，又忽悠不到钱了，然后从次要且性价比低的人开始裁。有些会边裁边招，比如要裁20%的，那就裁个30%，多10%空缺用来招人，注入点新鲜血液。至于“甘蔗”“同胞”，这话说的，非洲还有人每天饿死，什么是同胞，到了社会，只有永远的利益没有永远的朋友。你得创造价值，这样才能掌握主动权。至于心甘情愿，这事完全就是合同，签合同的时候自己就该多看看。法制社会，注意维权就行，如果真的不服，应该是想着去修改合同，劳动法，通过某些途径，或者干脆去找那些极其稳定的岗位。更何况如果你真是个被人吸食个两年就没有利用价值的“甘蔗渣”，那公司留你也只能算做慈善，哪天不做慈善也正确。【回答5】我是做技术的，我来说几句：在资源和人脉面前，技术就是一坨屎。先说观点：该问题是假命题，因为中年员工本身就是职场力量的最大群体，所以当企业开始大批量裁员的时候，这个群体必然也是被裁撤最多的。首先，我们要明确一个概念：“成人的世界不谈是非，只谈立场。”从社会层面来讲，确实是这样的，尤其是近几年经济形势太差，越来越多的企业在生死线附近挣扎。为了活下来，企业只能降低自身成本，而不可否认企业的人力成本是最直观可选项。退一万步，哪怕企业不裁员，最后结果大概率大家一起死。对企业来讲，最危机的时刻没有人会共情，有得永远都是无尽的索赔。所以，站在企业的角度，断腕求生是正确且必要的。企业如果这个时候考虑人性，那对企业和社会这都是不负责任的。站在被裁员的雇员角度，自己兢兢业业结果还是被裁，如果能获得合理的赔偿那还稍微心里好受点，然而现实是，一旦发生大规模裁员，经济赔偿大概率也肯定不尽人意。这个时候，被裁的一方不骂娘，那都是对企业的宽容。但是客观的讲，无论是因为行业原因还是企业自身原因被裁，这里面也跟自己的选择脱离不了关系。而且你不得不承认一个现实：在这个社会上生存，选择确实比努力要重要的多，我们囿于自己的知识储备、眼界等做出的选择和判断出现问题的时候，我们多半会归结于环境，而不会承认是自己的错误。从人性的角度，我们会与势弱者共情。但从现实角度上来看，我们往往迎来的会是保护强者的结局。因为保护强者更有利于社会的相对稳定，虽然很残酷，但这就是现实。比如闹得沸沸扬扬的停贷事件，大家对期房购买者的遭遇都很心疼，都在希望政府出面惩治房企。但事实上，惩治了房企，就能让大家拿到自己的房子么？很显然，这不可能。因为哪怕是另一个企业接手，也会考虑经济效益。把前人犯的错让后来企业承担这不符合市???经济的逻辑。所以，最优方案就是谁的锅谁背。综上，涉及到自身利益的时候，没有谁是甘心的。你应该庆幸，生活在相对公平的天朝之下，让我们普通人还有了那么一丝丝的机会。以上。==全文完==这真的正确吗？你怎么看？做了一个“反焦虑”的职场发展的社群：《40岁，创业2个月了，人生总得做点啥...》一年至少50场活动，欢迎大家加入。社群直播，8月份主题：职场晋升，欢迎参与。 阅读原文 跳转微信打开
你猜，微信多点登录+消息漫游，是如何实现的？（第89讲，超长文）
23 days ago
原创 58沈剑 2025-08-25 08:16 北京 架构师之路：架构设计中的100个知识点（89） 《架构师之路：架构设计中的100个知识点》89.多点登录+消息漫游有朋友问我说：1. 微信如何实现手机端、PC端同时登录，同时收消息？2. 微信能不能实现，换一个手机，仍能拉取到历史消息？这是多点登录和消息漫游的问题，结合自己的经验，聊聊相关功能的架构实现。什么是多点登录？以微信为例，可以PC端，手机端同时登录，同时收发消息。画外音：需要注意的是，一个端只能登录一个实例，例如同一个QQ号，在pc1上登录，再到pc2上登录，后者会把前者踢出，pc1会收到通知“你已在别处登录xxoo”。什么是消息漫游？在任何一个终端的任何一个实例登录，都能够拉取到所有历史聊天消息，这个就是消息漫游。画外音：微信目前只支持“多点登录”同时收发在线消息，以及最近几条消息的“消息漫游”，没有实现全部消息的“漫游”。典型即时通讯架构如何？典型即时通讯架构可以抽象成这么几层???1. 客户端：例如pc微信，手机qq2. 服务端：入口层gate：保持与客户端的连接；逻辑层logic、路由层router：实现业务逻辑，进行消息的路由；cache：用来存储用户的在线状态，与接入节点（用户具体连接在哪个gate节点）；db：固化存储消息，群信息，好友关系链等信息；画外音：都需要考虑高可用，扩展性。 一个典型的消息投递流程如上图步骤1-5：(1)...
心里门儿清，嘴却像被粘住？（程序员，你是不是经常这样？）
23 days ago
原创 paolo 2025-08-24 18:31 北京 你怎么看？ 心里明白，但说不清楚；或听对方表达，总是抓不住重点。对于很多技术人来说，或多或少都有类似问题。对于沟通中的表达与理解，我有一些看法。首先，毋庸置疑，沟通和理解能力非常重要。与产品经理沟通需求时，需要能听懂产品需求、表达清楚技术方案；过程中难免会有变更，如何理解变更、说清其对技术方面的影响，都是非常重要的场景，且会深度影响项目团队的协作效率和交付质量。往往技术出身的同学总是疏于修炼这方面的内功，导致在类似场景中比较被动。对我而言，很早就意识到这一点，投入了更多精力学习理论并实践，因此目前的职业发展并未被该技能拖累。在团队中，沟通方面的软实力也是我经常强调的，我会和大家分享一些技巧和方法，但关键还是看个人是否意识到需要主动提升。身边的例子：一个老旧系统的改造重构项目，面向公司全员，产品需求文档分散且庞杂，但该涵盖的内容都写了。背景是：前端新来的开发（RD），这是他带的第一个项目，对现状不了解，却强势且激进；后端有一位资深开发带两名年轻开发与之对接。前后端由于想法不一致，在技术实现方案上产生了众多分歧。比如，前端希望后端对不存在的字段也返回默认空串；一些校验在前端实现复杂，希望由后端校验；将通用接口拆分成定制化接口等。双方沟通时各说各话，经常以争吵结尾，不仅效率低下，还影响了整个项目团队的氛围。作为负责人，在与团队成员沟通后，我了解到：前端开发在表达过程中态度强势，过于强调这些调整对前端项目的收益，无视后端的反馈，导致后端产生严重的逆反心理，陷入对抗情绪，无法理性表达事实，形成了恶性循环。这是我需要解决的问题，总结的方法有以下几点：1. 耐心倾听，找到对方表达的核心内容。在沟通过程中，不少人缺乏倾听的技巧：没听完对方的表达，就臆测内容、打断对方，急于阐述自己的观点。这会导致信息传递被曲解、不完整，影响效率，也会让对方因被打断而产生情绪。建议大家一定要等对方表达完整，再结合自己的理解复述一遍，确认是否准确把握了对方的核心诉求。2. 站在对方身边而非对面，杜绝零和博弈，寻求双赢解法。针对上述例子，后端开发在理解了前端开发的主要诉求后，不要只想着 “你改还是我改”“你输还是我赢”，而要从双方都能受益的角度探讨方案，往往会有好的结果 —— 充分沟通后，问题很可能就能解决。3....
什么叫裁员裁到大动脉？
24 days ago
58沈剑 2025-08-23 20:35 北京 欢迎大家讨论！ 裁员裁到大动脉是指企业本来只想裁掉一些次要的、无关紧要的人员，却不料错误???把重要人员当做是无名小卒给裁掉了，从而使企业生产被动、经营管理困难。主题：什么叫裁员裁到大动脉？https://www.zhihu.com/question/638484057【回答1：1.2W+赞同】这就不得不提一嘴腾讯了，虽然那一天，所有的游戏都登录不上了，但是充值接口一直正常。【回答2：2.3W+赞同】不好意思张总，我被裁以后考上公务员了，今天代表税务局来调查一下贵公司在我入职期间偷逃税款的事情，希望你配合。【回答3：2.7W+赞同】我同学在中科院下面一个研究所，组里经常有人十天半个月不来，别人也发现不了。后来日子过得紧，把保洁阿姨裁了，大家立即都发现了，因为垃圾桶满了，没人收了。【回答4：3W+赞同】突然想到，陕西奥凯电缆有限公司。一名员工无故被裁员之后，在网上发布文章，名为《西安地铁你们还敢坐吗？》的贴文。称西安地铁三号线存在重大安全隐患。电缆偷工减料，整条线路的电缆都不符合地铁施工标准。电缆线径的实际横截面面积小于标称横截面积，造成电缆发热量过大，不仅消耗大量的动力还可能会引发火灾。因为是内部举报，又涉及到生产安全，所以迅速霸占热搜，神仙都压不住。后续的结果就是大家知道的，西安开发布会，副市长道歉，国家下来抽查没有一个合格的。结果国务院问责，从省里到地方负责人全部问责道歉。并逮捕企业八人。法人无期徒刑，其他的???几年十几年的都有。地方处理122人，厅官16人，58名处级，并有19人立案侦查。另外全国地铁安全大排查。这一刀下去，割的是脖子上的大动脉，是自杀。【回答5：4W+赞同】看了这么多答案，感觉这个图最应景。以上。==全文完==这个问题，你怎么看？做了一个“反焦虑”的职场发展的社群：《40岁，创业2个月了，人生总得做点啥...》一年至少50场活动，欢迎大家加入。社群直播，8月份主题：职场晋升，欢迎参与。 阅读原文 跳转微信打开
为什么我会觉得，管理岗好虚！（心里好慌...）
26 days ago
原创 58沈剑 2025-08-22 08:15 北京 我也曾经... 社群5月份话题：管理转型我，身处专家岗位的时候，就在想：“管理岗位感觉没啥真才实学，太虚了，我到底要不要转管理？”我，身处管理岗位之后，仍在想：“总觉得不稳，随时可能被裁，管理到底能不能成为自己的核心竞争力？”你，有没有类似的困惑？以下是我曾经的一些元认知思考与PEACE行动，分享给你。画外音：刚做技术经理时的思考。【1】管理有没有价值？能不能成为???心竞争力？ 元认知深度思考：对于工程师，架构师，技术经理，我心中什么是“有价值”？画外音：元认知，是社群内的核心工具。1. 工程师：写代码又快又好，交付的系统没有bug，这样的技术人产品喜欢，有价值；2. 架构师：结合业务做好架构，高可用，高性能，可扩展，这样的架构师，经理喜欢，有价值；3. 技术经理：能够带队达成目标，帮助业务赋能，帮助员工成长，这样的管理者老板喜欢，也有价值。是呀，技术人，架构师，经理，只是分工不同，在不同岗位发挥价值，有着不同的能力模型，这一点我怎么会不认同呢？对于管理，我心中什么是“核心竞争力”？代码，我写得好，别人写的不好，是我的核心竞争力。架构，我设计得好，别人设计得不好，是我的核心竞争力。管理呢？相同的团队，不同管理能力的经理来带，结果会一样吗？例子1：项目交付有的团队项目交付通常按时、按预算且高质量完成。风险控制更为有效，遇到的问题能够及时得到解决。兄弟团队配合顺畅，项目合作丝滑。而有的项目交付经常出现延期、或质量问题。项目管理混乱，遇到的问题得不到及时解决，影响项目进展。兄弟团队吐槽抱怨，项目合作不畅。为什么？例子2：团队士气有的团队士气高涨，工作氛围积极。员工感到被认可和支持，愿意积极贡献和创新。成员之间的协作顺畅，沟通高效。而有的团队士气低落，工作氛围紧张或消极。员工成员感到缺乏支持和认可，工作积极性低。成员之间的沟通和协作存在障碍，容易出现冲突。为什么？例子3：团队发展有的团队能够吸引到，招聘到高素质的人才。员工的流动性低，忠诚度和满意度高。员工晋升比例高。而有的团队招聘难度大，难以吸引优秀人才。员工流动性高，员工忠诚度和满意度低。员工晋升比例低。为什么？…在上面的123里，经理能做功吗？显然能。不同的结果，能体现管理的差异吗？显然能。那管理的核心竞争力是什么呢？类似于工程师，架构师。我管理团队，能拿到别人拿不到的结果（项目结果，团队士气，人员发展…），就是我管理上的核心竞争力。【2】那为什么，我会觉得管理“虚”呢？元认知深度思考：我觉得技术岗位来得实在，因为我对技术工作了解，每天都在干相关的工作。我觉得管理岗位虚无缥缈，可有可无，没有价值，因为我对管理工作不了解，只是看着别人在做。那我就是在YY。这是典型的“自利性偏差”。我总会觉得，自己熟悉的“实”，自己不熟悉的“虚”。原来，这些困惑，是我自己的问题。觉得不踏实，是因为我自己的 “失控感”：1....
跳脱职场小河，拥抱大海：那些早已启航的人在做什么？
26 days ago
原创 余烬 2025-08-21 20:36 北京 共勉！ 职场之路如果能规划，典型出路在哪里？我心中的职场出路，有两种。一种是可以让我在职场脱颖而出的路。一种是可以让我走出职场的路。第一种是我曾经寻找的路，第二种是我当下想走的路。职场是不确定的，不是只有努力和能力这两个影响因素，还有人与人之间的频率，尤其是你和你领导之间的频率。如果你只为自己留第一种路，就像有句话说的那样：“人们总是记得自己在一条船上，而忘了自己在一条河上。”职场的不确定性，某些领导的 PUA，都会让你陷入深深的自我怀疑。如果你意识到第二种出路，那你就是接受了职场的不确定性，你的视野才有可能遍布整条河流、旷野、海洋、宇宙。如果时间能回到初入职场的那年，我会告诉那时的自己：“年轻人，请带着离开职场的心，进入职场。”如果你想着终有一天会离开职场，就不会以公司的期望作为自己的期望，你会选择自己真正想做的岗位、方向，并通过各种可能的方式让公司看到这个岗位和方向的价值，从而能够借助到公司的资源，成就你对自己的规划。多年前，有一些做项目的软件企业，经济环境好，项目多的时候，这些企业最看重的就是项目经理，你会发现很多项目经理都是程序员背景，因为这些企业经常做的就是把技术能力成长较快的研发人员，转型为项目经理。有一些技术人员转型项目经理仅仅是为了迎合公司的期望，因为能升职、加薪，而没有问过、想过自己真正想要做什么。时间久了，就出现了想做回技术，但是怕自己做不了的纠结和感慨。另一方面，技术人刚刚成长为能独当一面，就被转去做项目经理，也导致了企业技术人才的青黄不接，项目的推进和验收的难度也越来越大。我也有过这样的经历。从研发转项目经理的3个月后，好在我感觉到自己还是喜欢技术，主动找到领导给我转回到技术岗。三年后，我拿到公司比较看重的高级系统架构师软考证书，同一年也从项目组进入了公司技术研究院。在那个时间点往回看，我感谢自己主动转回技术岗的???定。人只有在做自己喜欢或擅长的事的时候，才可能有出路。进入公司技术研究院的那年，ImageNet、李飞飞、机器学习、吴恩达，这些人工智能领域的名词和名字开始在网络上传播。计算机竟然可以分辨出猫和狗的图片，竟然能从图片中识别出人和车，竟然可以把梵高的星空风格轻松地迁移到我自己的日常照片上。于是我主动斩断我的职场连续性，开启了一条新的职场曲线。我的决定，很自然地让我失去了一些机会，因为那时公司的所有业务和项目对AI的需求并不大。而我当时的想法是，AI是我不工作了，也会想持续关注和精进的领域。那时，我的人工智能基础几乎为零。之后的三年，线性代数、微积分、统计学、数据分析、机器学习、深度学习。我在工作之余，学完了斯坦福、麻省理工、加州理工、可汗学院的相关公开课程。写完了15本笔记后，我开始读YOLO、Transformer、BERT这些经典论文。在知乎上提的一个关于Transformer论文中的问题，没想到关注度超过了50万，这无疑是一个好问题，也给了我很多鼓励。又过了三年，AI逐渐进入各行各业，公司决定 all in AI，我踏上了那条职场脱颖而出的路。故事还没结束。如今，大模型时代的到来，正在彻底改变众多行业的范式。有些人看到被代替，有些人看到自己的生产力得到大幅增益。而我正在走向那条走出职场的路，这条路有太多的挣扎、困惑、迷茫。在云开月明之前，我选择让自己随心流动，继续前行，就像李娟在《九篇雪》中写的那样：“一切走在必经之途上，一切毫无意外，一切无需后悔。”说明，这是一个，社群六月份的活动：1. 隶属主题：职业规划2....
一篇文章讲清楚，过载保护+负载均衡（第88讲，超长文）
28 days ago
原创 58沈剑 2025-08-20 08:15 北京 架构师之路：架构设计中的100个知识点（88） 《架构师之路：架构设计中的100个知识点》88.负载均衡，异构服务器过载保护什么是负载均衡？负载均衡是指，将请求/数据分摊到多个操作单元上执行，关键在于均衡。负载均衡通常是怎么做的？service层的负载均衡，一般是通过service连接池来实现的，调用方连接池会建立与下游服务多个连接，每次请求“随机”获取连接，来保证访问的均衡性。负载均衡、故障转移、超时处理等细节也都是通过调用方连接池来实现的。然而，后端的服务器有可能硬件条件不同：1. 如果对标低配的服务器“均匀”分摊负载，高配的服务器利用率会不足；2. 如果对标高配的服务器“均匀”分摊负载，低配的服务器会扛不住；能否根据异构服务器的处理能力来动态、自适应进行负载均衡，以及过载保护呢?调用方连接池能否，根据service的处理能力，动态+自适应的进行负载调度呢？方案一：可以通过“静态权重”标识service的处理能力。最容易想到的方法，可以为每个下游service设置一个“权重”，代表service的处理能力，来调整访问到每个service的概率，如上图所示：1. 假设ip1，ip2，ip3的处理能力相同，可以设置weight1=1，weight2=1，weight3=1，这样三个service连接被获取到的概率分别就是1/3，1/3，1/3，能够保证均衡访问；2. 假设ip1的处理能力是ip2，ip3的处理能力的2倍，可以设置weight1=2，weight2=1，weight3=1，这样三个service连接被获取到的概率分别就是2/4，1/4，1/4，能够保证处理能力强的service分到等比的流量，不至于资源浪费；Nginx就具备类似的能力。方案优点：简单粗暴，能够快速地实现异构服务器的负载均衡。方案缺点：权重是固定的，无法自适应动态调整，而很多时候，服务器的处理能力是很难用一个固定的数值量化。方案二：通过“动态权重”标识service的处理能力。如何来标识一个service的处理能力呢？服务能不能处理得过来，该由调用方说了算：1. 调用服务，快速处理，处理能力跟得上；2....
为了保护源代码不被员工泄露，你猜公司都???了哪些招？
28 days ago
58沈剑 2025-08-19 20:35 北京 你怎么看？ 有童鞋提问，公司如何保护源代码不被员工泄漏？比如防止员工复制上传什么的。目前搜到了沙箱跟虚拟化两种方案，但不知道怎么操作。也不知道还有没有其他的，真愁啊！主题：公司如何保护源代码不被员工泄漏？https://www.zhihu.com/question/54423554【回答1】上策，给够钱，收其心。就算离职，员工对公司还是感恩戴德。中策，权限控制，每人只能看到一部分。定规矩，严审计，触及红线，法律伺候。下策，学银行，每天下班，老板把源码锁进保险箱，别笑，真有这么干的。【回答2】参考华为的技术方案。员工的工作台在数据中心，员工手上的终端只能远程登录到数据中心的工作台去开发代码。每一台接入的终端，都需要接入认证。这些终端，物理连接在公司的内网。还有一些非重要部门的代码，允许正式员工的笔记本下载到本地。这些笔记本也是接入认证和硬盘加密的。员工对手上的笔记本信息安全负责。【回答3】大多数公司的代码，其实对于外界来说并没有什么价值，只是管理者误以为有价值，才浪费资源去防止泄漏。这就好像私房照，自己担心得要死，但其实泄漏了，别人根本也懒得去看一眼。当然，比方说像陈冠希这样，那是需要严格防止泄漏代码的，那么上虚拟化是业界最成熟的方式。但首先要考虑一下，自己公司有没有一万名员工，盈利模式是否支撑得起每年砸几亿去搞这些IT基础设施。如果不是，那一般还是不用去考虑代码泄漏的问题。【回答4】绝大部分的公司（BAT另说) 手中的源代码商业价值根本不高。绝大部分的公司的源码质量都比不过GitHub的那些开源类库。绝大部分的公司的源码都属于高度定制化的开发（就是换个公司，这个软件几乎就没有什么价值了）。绝大部分的公司都不是靠“软件技术”赚钱的。绝大部分的人都不会傻到直接把偷来的源码用于“商业活动”（非但不一定赚钱还可能吃官司,还不如去GitHub上扒开源代码)。“防御”的成本数倍于“重新开发一套”软件。所以看淡一点源码，它在绝大多数公司中其实“并不值”几个钱，虽然它的创造成本可能很贵。【回答5】先说结论: 别费那神气了，不值得。有人说除非BAT，事实上就是BAT有很多代码都没什么特别的保护，员工能接触到就能随便复制。唯独就是越核心越底层的代码，能接触到的人越少需要的权限越高罢了。普通的研发，接触到的代码本来就很表层，而且范围通常也不会很广，仅限自己负责的一亩三分地，你复制出去有什么用？没有底层支持你能跑起来？没有大佬维护你敢用在生产业务上？说不定没有个熟悉这套业务的大牛，你连怎么跑起来都摸不到门。更何况真被人拷出去用起来在生产业务了，再给人发律师函也行，大厂的法务都吃这口饭的。如果都发现不了，那说明也没啥大不了的。小公司就更没什么了，你代码再牛逼毕竟承载的业务就那么大，全套复制出去别人也不一定看得上，写得再好好得过知名的开源项目么？业务代码别人业务能完全一样么？就算真一样以后不做新功能的么，没有Bug要修的么？而且还可能有些只有原作者才知道的坑，业务上根本没法复用。与其担心这个，不如多花点心思想想怎么留住核心技术人员不流失。这才是小公司的核心资产，代码并不是。以上。==全文完==这个问题，你怎么看？做了一个“反焦虑”的职场发展的社群：《40岁，创业2个月了，人生总得做点啥...》一年至少50场活动，欢迎大家加入。社群直播，8月份主题：职场晋升，欢迎参与。 阅读原文 跳转微信打开
为了保护源代码不被员工泄露，你猜公司都想了哪些招？
28 days ago
58沈剑 2025-08-19 20:35 北京 你怎么看？ 有童鞋提问，公司如何保护源代码不被员工泄漏？比如防止员工复制上传什么的。目前搜到了沙箱跟虚拟化两种方案，但不知道怎么操作。也不知道还有没有其他的，真愁啊！主题：公司如何保护源代码不被员工泄漏？https://www.zhihu.com/question/54423554【回答1】上策，给够钱，收其心。就算离职，员工对公司还是感恩戴德。中策，权限控制，每人只能看到一部分。定规矩，严审计，触及红线，法律伺候。下策，学银行，每天下班，老板把源码锁进保险箱，别笑，真有这么干的。【回答2】参考华为的技术方案。员工的工作台在数据中心，员工手上的终端只能远程登录到数据中心的工作台去开发代码。每一台接入的终端，都需要接???认证。这些终端，物理连接在公司的内网。还有一些非重要部门的代码，允许正式员工的笔记本下载到本地。这些笔记本也是接入认证和硬盘加密的。员工对手上的笔记本信息安全负责。【回答3】大多数公司的代码，其实对于外界来说并没有什么价值，只是管理者误以为有价值，才浪费资源去防止泄漏。这就好像私房照，自己担心得要死，但其实泄漏了，别人根本也懒得去看一眼。当然，比方说像陈冠希这样，那是需要严格防止泄漏代码的，那么上虚拟化是业界最成熟的方式。但首先要考虑一下，自己公司有没有一万名员工，盈利模式是否支撑得起每年砸几亿去搞这些IT基础设施。如果不是，那一般还是不用去考虑代码泄漏的问题。【回答4】绝大部分的公司（BAT另说) 手中的源代码商业价值根本不高。绝大部分的公司的源码质量都比不过GitHub的那些开源类库。绝大部分的公司的源码都属于高度定制化的开发（就是换个公司，这个软件几乎就没有什么价值了）。绝大部分的公司都不是靠“软件技术”赚钱的。绝大部分的人都不会傻到直接把偷来的源码用于“商业活动”（非但不一定赚钱还可能吃官司,还不如去GitHub上扒开源代码)。“防御”的成本数倍于“重新开发一套”软件。所以看淡一点源码，它在绝大多数公司中其实“并不值”几个钱，虽然它的创造成本可能很贵。【回答5】先说结论: 别费那神气了，不值得。有人说除非BAT，事实上就是BAT有很多代码都没什么特别的保护，员工能接触到就能随便复制。唯独就是越核心越底层的代码，能接触到的人越少需要的权限越高罢了。普通的研发，接触到的代码本来就很表层，而且范围通常也不会很广，仅限自己负责的一亩三分地，你复制出去有什么用？没有底层支持你能跑起来？没有大佬维护你敢用在生产业务上？说不定没有个熟悉这套业务的大牛，你连怎么跑起来都摸不到门。更何况真被人拷出去用起来在生产业务了，再给人发律师函也行，大厂的法务都吃这口饭的。如果都发现不了，那说明也没啥大不了的。小公司就更没什么了，你代码再牛逼毕竟承载的业务就那么大，全套复制出去别人也不一定看得上，写得再好好得过知名的开源项目么？业务代码别人业务能完全一样么？就算真一样以后不做新功能的么，没有Bug要修的么？而且还可能有些只有原作者才知道的坑，业务上根本没法复用。与其担心这个，不如多花点心思想想怎么留住核心技术人员不流失。这才是小公司的核心资产，代码并不是。以上。==全文完==这个问题，你怎么看？做了一个“反焦虑”的职场发展的社群：《40岁，创业2个月了，人生总得做点啥...》一年至少50场活动，欢迎大家加入。社群直播，8月份主题：职场晋升，欢迎参与。 阅读原文 跳转微信打开