但是这些都不是我这个学弟和我吐槽的点，他真正和我吐槽的是，他很不能理解，这位新来的技术总监竟然禁止公司内部所有开发使用Lombok。但是又没给出十分明确的，可以让人信服的理由。...另外，关于Lombok的使用，不同人有不同的看法，因为很多人都使用过Lombok，对于他的优点都比较了解，所以接下来我们重点说一下Lombok的使用会带来哪些问题。 Lombok有什么坏处？...这就可能得到意想不到的结果。 影响升级 因为Lombok对于代码有很强的侵入性，就可能带来一个比较大的问题，那就是会影响我们对JDK的升级。...但是并不意味着Lombok的使用没有任何问题，在使用Lombok的过程中，还可能存在对队友不友好、对代码不友好、对调试不友好、对升级不友好等问题。...最重要的是，使用Lombok还会导致破坏封装性的问题。 虽然使用Lombok存在着很多方便，但是也带来了一些问题。
我有个学弟，在一家小型互联网公司做Java后端开发，最近他们公司新来了一个技术总监，这位技术总监对技术细节很看重，一来公司之后就推出了很多”政策”，比如定义了很多开发规范、日志规范、甚至是要求大家统一使用某一款...但是这些都不是我这个学弟和我吐槽的点，他真正和我吐槽的是，他很不能理解，这位新来的技术总监竟然禁止公司内部所有开发使用Lombok。但是又没给出十分明确的，可以让人信服的理由。...另外，关于Lombok的使用，不同人有不同的看法，因为很多人都使用过Lombok，对于他的优点都比较了解，所以接下来我们重点说一下Lombok的使用会带来哪些问题。 Lombok有什么坏处？...但是并不意味着Lombok的使用没有任何问题，在使用Lombok的过程中，还可能存在对队友不友好、对代码不友好、对调试不友好、对升级不友好等问题。...最重要的是，使用Lombok还会导致破坏封装性的问题。 虽然使用Lombok存在着很多方便，但是也带来了一些问题。
这个问题也太好了，涉及到Paxos和Raft的原理以及优化。 先肯定题主的理解，是正确的。 Raft的一致性检查，是Follower接受某个日志项的条件，也确实是控制Raft串行协商的关键之处。...既然这里是为了证明Paxos的并行协商不一定优于Raft的串行协商，所以这里不讨论采用串行协商带来的坏处，和并行协商的好处，另外这些也不难总结。...但是Raft是串行协商的，并且引入了Leader，可以有很多优化方案，例如：Leader Read，Follower Read，Lease Read。...Paxos的并行协商坏处 并行协商确实给Paxos带来很多好处，例如，灵活性，优于Raft的可用性。...Leader Read，Follower Read，Lease Read是否能应用于Paxos，暂时还没有思考，可能能应用的条件也是需要引入一个中央权威成员吧。 Raft的串行协商是否能够优化？
在微服务架构中，需要调用很多服务才能完成一项功能。服务之间如何互相调用就变成微服务架构中的一个关键问题。...用事件驱动的好处是降低了耦合度，坏处是你现在不能在程序里找到整个购物过程的步骤。 如果一个业务逻辑有它自己相对固定的流程和步骤，那么使用RPC或业务流程管理（BPM）能够更方便地管理这些流程。...但这样建立的服务组合可能只适合一个程序使用，没有多少共享价值。因此如果有合适的场景就采用，否侧也不必强求。虽然我们不能降低RPC服务之间的耦合度，却可以减少这种紧耦合带来的影响。...降低紧耦合的影响 什么是紧耦合的主要问题呢？就是客户端和服务端的升级不同步。服务端总是先升级，客户端可能有很多，如果要求它们同时升级是不现实的。...它们有各自的部署时间表，一般都会选择在下一次部署时顺带升级。 一般有两个办法可以解决这个问题： 同时支持多个版本：这个工作量比较大，因此大多数公司都不会采用这种方式。
用事件驱动的好处是降低了耦合度，坏处是你现在不能在程序里找到整个购物过程的步骤。 如果一个业务逻辑有它自己相对固定的流程和步骤，那么使用RPC或业务流程管理（BPM）能够更方便地管理这些流程。...第二，如果你要想修改事件或事件的格式就比较麻烦，因为旧的事件已经存储在Event Store里了（事件就像日志，是只读的），没有办法再改。...但这样建立的服务组合可能只适合一个程序使用，没有多少共享价值。因此如果有合适的场景就采用，否侧也不必强求。虽然我们不能降低RPC服务之间的耦合度，却可以减少这种紧耦合带来的影响。...降低紧耦合的影响 什么是紧耦合的主要问题呢？就是客户端和服务端的升级不同步。服务端总是先升级，客户端可能有很多，如果要求它们同时升级是不现实的。...它们有各自的部署时间表，一般都会选择在下一次部署时顺带升级。 一般有两个办法可以解决这个问题： 同时支持多个版本：这个工作量比较大，因此大多数公司都不会采用这种方式。
（在和很多互联网的朋友聊过之后，在互联网企业很多并没有后台的概念，更多直接使用平台的概念，例如分为前台层和平台层，但位置和作用与传统企业里的后台相似，我这里直接统一使用后台这个概念来代表。）...定义了前台和后台，我们再回过头来看企业为什么要建中台这个问题 我们看到很多企业的后台，在创建之初的目标，并不是主要服务于前台系统的业务创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题...譬如客户名有重复，从业务模型来看，是不能有重复的。...4.2 与销售易系统双向同步有字段遗漏 4.3 与销售易系统双向同步没有处理删除场景 缓存架构升级 5.1 现状：目前使用了本地缓存。...既不能没有日志，两眼一抹黑；也不能因为打的日志过多，导致扰乱了关键点，影响排查问题，譬如一个接口打了100多条日志，翻了好几页，也没找到关键的点。
同时，也能反映出你的学习能力、理解能力，以及遇到了什么层级的问题，而你又是如何思考解决的。 其次，日报的格式排版，是否有错别字，则反映了你做事的认真程度和对自身的要求有多高。...这里只说我认为重要的几点： 提问之前一定要思考过，尝试过，至少百度过； 如果有一些问题是有现场的，一定保留好现场再去问，否则无从谈起； 该交代的上下文要简明扼要说清楚，不能不交代，也不能事无巨细全都说一遍...那么针对这本书，你就要先浏览目录，看看哪些才是真正的精华部分，或者是你没有掌握的东西，有目的的去看会节省很多时间。...那么主动承担有没有坏处呢？当然有：1，你要有自信；2，你要更努力；3，没有了 … 可是，你觉得这算是坏处吗？难道你什么都不主动承担，就不需要增强自信不需要努力了吗？图样。...分享沉淀 前面说了这么多，虽然没有直接提到成长的问题，但是所有主题都是在围绕成长的细节在展开。那么，当你按照这些一步一步走下来的时候，你怎么确定自己真的成长了呢？
虽然缺乏 Hadoop 系统的开发或使用经验，但是我觉得并没有妨碍我对这篇论文的理解。在我的脑子里，HDFS 就是 GFS，HBase 就是 BigTable。...为了系统升级独立方便，使客户端兼容不同版本的 Hadoop RPC 是自然而然的事情。 HDFS 在分配副本数据块位置时，虽然会考虑到机架位，但整体来说仍然是相当随机的。...会丢很多数据。...打造实时生产坏境的 HBase 3.1 行级别原子性和一致性 虽然 HBase 已经保证了行级别的原子性，但节点宕机可能导致最后一条更新日志不完整。...可能还需要再去了解 HBase 的功能才能有答案。 从这个系统的很多细节可以发现，有不少折中和 trick。我想这就是现实世界，凡事很难做到尽善尽美，工程也一样。
因为流量太大，如缓存高带宽的情况，交换机上联端口或者服务器千兆网卡很快被打满； ● 监控缺失：出了问题技术团队不知道，骑手或用户说不能下单了之后各种投诉，由客服反馈过来； ● 单点：从业务到整体架构到每个业务甚至机器都存在很多单点...网络架构持续升级 早期我们有一个数据中心，使用的核心交换机是华为的5700SE，这意味着什么？在一次流量突发中，这个设备引发了我们P0级的事故。...这个要看业务的容忍度，我们有一些业务堆日志说一条都不能丢，我们测试下来UDP有30%-50%的丢弃，如果说对日志完整性要求很高，不建议使用。...A：关于这个问题，我和阿里也聊过，他们做了3次探索。第一个是开发开发，开发好了给运维用。很多公司都会这么做，这么做有一个坏处：运维说你开发的是什么东西，我不愿意用；开发就说运维一天到晚就知道提需求。...这样的坏处是：开发对运维理解不深刻，运维系统和线上业务开发是很不一样的，运维系统对可靠性要求相对差，但是对质量和效率的要求很高。开发不懂运维，容易出现各种故障。
Agent技术能解决什么问题 既然Agent技术被如此广泛的运用，那么它主要是为了解决什么问题呢？ 要充分理解它，我们需要从Agent的特点去考虑。...你可能会说怎么会有这样的日志框架，可能大家用Log4J或Logback这样的日志框架都太过于强大了，事实上其他语言真的有这样的，而且日志框架也有很多轮子，质量参差不齐。...不能要求每个日志框架都具备同等的能力，只能通过一个Agent进程来处理。...Agent关键技术和缺点 Agent关键技术有很多，看起来不难，但要做好，确实得下很多功夫： 资源隔离，这点通常使用cgroups技术 Agent生命周期管理，包括Agent的上线、升级、灰度、下线等等的管理...proxyless Mesh 最后说一句 虽然看完本文你也不知道怎么实现一个Agent，但通过本文你能了解到Agent技术是什么，有什么好处，大厂为什么偏爱这项技术，以及要实现一个Agent的技术关键点和缺点各是什么
之所以病毒多主要还是用户多，很多人觉得这个系统病毒多，树大招风用的人多自然出问题也会多，linux倒是病毒少主要使用的人员还是技术人员。...大版本的升级也是非常必要的，但中间过程还是会有波动，个人始终觉得xp系统是一个非常稳定的版本，到现在家里的老电脑还在用的这个系统，但是遗憾的是很多软件已经不能使用了，打开软件直接提醒让升级，不升级不让用...，有很多人觉得现在的硬件配置都这么高了，电脑的软件升级的更加夸张，也就是增加的那点硬件配置还不够软件升级带来的冲击大，现在的很多软件对于硬件的要求已经没有底线了。...现在操作系统大趋势向着空间换时间的概念，为了运行效率在运行之前提前加载一部分内存，这样做还容易减少内存碎片的产生,提升内存的使用效率，但这种做法有个坏处是软件还没怎么运行内存就被占据了一大半，所以不能只是盯着硬件提升了多少...即使如微软这种超级大公司发布操作系统之前肯定有全面的压力测试，还还是会出现各种各样的问题，其实大家都忽略了一个很重要的问题，现在的硬件厂家太多，要做到多种硬件的兼容需要付出很多的精力，不同于苹果的ios
对员工来说，最大的好处是，减少了通勤时间，可以更灵活地安排自己的工作。 对员工来说，最大的坏处是，工作效率可能会变得很低。首先，沟通成本增加了，因为远程沟通，很容易导致理解上的错误。...根据周边朋友的反馈和我自己的经验，我觉得主要原因有三个： 1. 家庭琐事的打扰。特别是有小孩的家庭，在居家办公期间，会经常被一些杂事打断。 2. 没有了工作环境的这种氛围，很多人就很难进入工作状态。...据我了解，很多人在居家办公的时候是会玩游戏的，我相信在办公室你是不会这么做的。 3. 居家办公确实不便于协作，这是客观现实。虽然现在很多办公软件在试图解决这些问题。但只能改善，不能根本解决问题。...我有朋友说他们试过效果并不好，很多同事在白天确实会受一些因素导致当日工作不能按时完成，只能在下班时间点之后找时间赶上来。所以这个晚汇报，大家可以根据自己的情况选择做不做。...比如项目协同工具，用teambition、worktile，它可以通过可视化的方式展现团队的工作成果。同时跟项目相关的信息也可以做到快速的查找。相比微信群会方便很多。 还比如飞书里有个飞阅会。
前言： 在把gpt等自然语言模型融合到底层的时候，我遇到了数不清的困难，虽然大多都解决了，但仍有一些硬伤。...原因其实也很简单，我们知道，AI模型的基本结构是很多个中间节点，中间节点有多少层？每层是干嘛的? 每层又有多少个？这些决定了最终的输出结果。...但是我们作为测开工程师，一定不能放弃，更不能坐等新的gpt出山。办法目前有以下几种： 1. 拆分文案：把大段的完整文档，拆分着让gpt来解析。...多重试验：虽然大段文档的解析成功率降低了，但是毕竟还是有成功率的，可以写个循环来多次解析，直到成功。这样的好处是逻辑简单，但坏处也很明显：够笨，够慢，成本翻几倍。 3....产品思维有时候也受到底层技术限制，当底层实在无法突破的时候，产品经理会用自己的新设计来转移痛点，化痛点为爽点。而且这个设计也会更加精准和专业，之后可以进行更多的升级空间。
此时我更想增加一个阶段叫需求驱动，需求驱动可以理解成一种高级形式，更应该是一种原点模式，就是那个最初的动力。对于一个创新型企业来说，需求的理解更是成功的关键，而创新的引领点是对客户需求的把握程度。...现在回想起来，我们错误的预设了服务内容和前提，并以此内容发起问题调查，给到的结果让我很意外——运维自动化不是核心需求而日志分析是核心需求（如下图）。...而单场景多角色，是满足多个角色的相同场景需求，比如说日志分析需求，开发、测试、运维甚至是安全人员都有相应的日志分析需求。...有意思的是，现在很多创业者打了很多云stack的旗号，从低到上、从前到后完全提供全栈的服务能力（这是一种贪婪策略），想想都知道IT能力的专业化需要很长的时间积累，否则没法去真正引导客户需求。...经验是助力也是桎梏，隐性需求的思考是突破桎梏的关键。当下互联网的经验的确体现出优势，但不要让该经验凌驾于客户需求之上，更不能凌驾于产品之上，只因他有好处也有坏处。
目前官方推荐的部署方式，大幅简化了 Kubernetes 的部署复杂度，但依旧需要较多的手动操作，而且这和在裸机上部署是没有任何区别的，对 Kubernetes 没有任何的功能增强。...虽然没有全部查证，但我相信所有的主流自动化部署工具都有成熟的 Kubernetes 部署方案，例如 Ansible、Puppet、Salt、Terraform、Nomad 和 Chef 等。...这比 kubeadm 的好处是，自动化部署，不需要手动干预，但如果部署好 OpenStack 虚拟机后，安装 Kubernetes 的执行时间过长的话，还是不能直接使用，依旧要做镜像，和注入个性化数据。...上部署，同时好处是对 Kubernetes 做了增强，支持多租户，有更好的界面和使用体验，可以作为备选之一，但可能的坏处是，需要深入的理解 Rancher 的开源代码，以及和 Kubernetes 的集成度...，以及软件升级问题，需要考虑。
此外，在使用 RPC API 过程中，我们特别需要注意兼容性问题，二方库不能依赖 parent，此外，本地开发可以使用 SNAPSHOT，而线上环境禁止使用，避免发生变更，导致版本不兼容问题。...所谓思维模型，我的理解是针对问题域抽象模型，对域模型的功能有统一认知，构建某个问题的现实映射，并划分好模型的边界，而域模型的价值之一就是统一思想，明确边界。...此外，随着微服务的普及，我们的服务越来越多，许多较小的服务有更多的跨服务调用。因此，微服务体系结构使得这个问题更加普遍。...2）如果不加栈信息，只是 new 自定义异常，加入自己的理解的 error message，对于调用端解决问题的帮助不会太多。...我们来看一个案例，假设“用户中心”某个接口没有权限获取资源而出现错误，我们的业务系统可以响应“UC/AUTHDENIED”，并且通过自动生成的 UUID 值的 request_id 字段，在日志系统中获得错误的详细信息
0x00 前言 本次讨论的主题是：数据维度分类中，习惯将无法归类或者数据模糊的归为“未知”,那么对于这些未知数据， 我们应该怎么处理呢? 问题： 1、“未知”对数据分析和可视化有什么影响？...0x01 讨论一： 在用户画像分析的时候经常会遇到未知数据，主要有两个原因： 1、数据采集时埋点未采集到该字段数据，上报空值； 2、没有收集到用户该字段信息，无法判断 讨论二： 我是做数据底层的 在数据日志上报端...讨论三 数据展示要完整 没有未知就是不完整的数据，可以观察数据分类和统筹情况，隐瞒未知虽然不会暴露问题，但是很多分析要建立在真实现有数据情况下才能成立，分类表总量也要体现出来，不能避重就轻，如果未知数据量过大...，准确性和完整性都得到不到满足，不就不能发现问题解决问题 坏处： 多数团队的成员水平参差不起，对数据“未知”的选项和造成“未知”的原因不了解，导致普及和沟通成本较大，如果“未知”数据量特效小，忽略这个选项有时候更佳...（ps： 减少了内部技术人员的精力损耗） 附图：不同级别的人员对对于类似问题解决的要求门槛 0x02 总结 对于这个话题，我觉得群友们的讨论已经很极致了，所以下面的文章中我就根据大家讨论的情况及个人的一些理解对这个话题进行一个整理与总结
WINDOWS SERVER 2008安装IIS 默认的服务器上没有IIS的我们要自己先安装一下，打下左下角的服务管理器 ? 右键点击“角色”，选择添加角色 ? 点击下一步进入 ?...选中Web服务器IIS，点下一步，因为我这是已经装完了，一下面里面的选项除了FTP就都打上勾吧，反正也没有坏处。 剩下的就是等待安装完成就可以了。...另外，目前.NET Core版本升级很快，请下载最新版本的.NET Core Windows Server Hosting，确保服务器上的.Net Core版本不低于部署的Asp.Net Core App...net Core因为我自己用的是.net Core2.0，所以你要下载后找到对应的版本进行安装，一开始我下了个2.1的结果不能用，最后又重新下的2.0解决的问题。...从日志里面可以拷贝出来看看错在哪，再找一下度娘就行了，我就是最后用这个发现我的.net Core装了2.1的还不行，必须又重新下载了2.0的安装才可以的 ---- 流程这样记录下来其实也挺简单，但是因为第一次配置
毕竟升级了 angular 大版本，随之而来的一些依赖库也需要跟着升级，这无可厚非，可以理解，所以当让我也升级 node-sass 时，我没啥反感。...但谁知道，node-sass 新版的下载需要依赖 C++ 的编译环境、需要依赖 python 环境，虽然到这里有点烦了，但还好，网上也很多人出现这问题，解决方案不难，如下： npm install --...小结 之所以以前正常，新项目出现种种问题，原因在于各环境的版本升级，所以，需要明确，各个环境、框架之间都是有依赖关系的，不是任意版本组合就可以的，比如： angular v8 版本就需要依赖 angular-cli...node-sass 编译错误时，注意日志，根据不同错误，搜索相关关键词，按网上教程解决，通常来说就是没有 python 环境、没有 c++ 编译工具、vs 版本过高等问题，可以试试通过 npm 安装...参考链接 以下是很多很多的链接，有的有提出解决方案，有的没有，自取： Cannot compile node-sass with Visual Studio 2019 installed Error in
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
云直播
