Hello World - labchy
type: channel
link: http://blog.38data.com/index.php/author/1/
description: labchy
items: 一些心得，不定期更新[2025-11]
items: 第七届世界智能制造大会
items: 工业领域下的OPC-UA网关设备
items: 管理心得，不间断记录
items: 涉密信息管理系统(分级保护评测)
items: 公司软件工程师设备记录
items: 软件架构师应该知道的97件事之概括
items: 安全可靠技术和产业联盟-会员单位介绍（2018）
items: 7大迹象，表明你的DevOps 做对了！
items: 新项目别一上来就用微服务

一些心得，不定期更新[2025-11]
type: item
date: 2023-11-20T14:50:00+08:00
description: 只要利益不发生冲突，别人说话一般不要去反驳。人际交往的高段位技巧，热情大方，一问三不知。你真正要做的事，连神明都不要讲，安静的做成功了再说，是以秘城，言以懈息。努力克制自己的情绪，学会赞美和闭嘴。给别人办事，一定要装的很难办，给领导送礼一定要装的很自然，给爱人花钱，一定要装得很痛快，请别人吃饭，一定要装得很大气，和人谈生意，一定要装得很成功，和人谈感情，一定要装得很纯洁，和人谈工作，一定要装得很专业，不能喝酒时，一定要装得很醉，不能赴约时,一定要装得很失落，不能帮忙时，一定要装的很难过。做人一定要有城府，逢人只说三分话，不可全抛一片心。你要是想看透人心，只需要落魄一次就够了。也为人在落魄的时候，身边的牛鬼蛇神都会露出真实面目。德不配位，财不配身，怎么破，很简单，就是习惯它，升官了，静默半年别折腾，赚钱了，放手里半年不花，就行了。处理问题，包括应急事件，狭路相逢和退一步海阔天空都不可取，通用的是沉默是金和让子弹飞，有奇效。刷视频，多看看打架斗殴、车祸集锦、意外身亡的，危机意识和避险意识会潜移默化。多读历史，人虽然会变得冷漠，但是能够提高生存能力，你死我活才是本质。社会感悟1、改命 选妻2、成事 借势3、立威 沉默4、服众 果断5、上位 贵人6、守业 制衡7、破局 舍弃8、避祸 低调9、谈判 底牌10、止损 狠心11、见识 远行12、人脉 主动13、机遇 胆识14、平安 示弱15、信任 靠谱16、人心 让利17、赚钱 信息差18、藏锋 糊涂19、人性 吃亏20、长久 后路买房要点1、判断房主是否着急售卖 看挂牌周期、降价记录； #调研#客观情况#时机2、不谈缺点，只说适合，表达想要； #输出#同理心3、哭穷，借的、经济不景气； #输出#同情心4、不说心理价位，只说越便宜越好； #输出#博弈5、与人打交道，心理博弈，让别人舒服； #方法论

第七届世界智能制造大会
type: item
date: 2023-05-19T23:42:09+08:00

工业领域下的OPC-UA网关设备
type: item
date: 2023-03-12T16:27:33+08:00
description: 前言OPC是什么?自20世纪90年代初以来，工业自动化领域内，基于PC和软件的自动化系统，特别是基于Windows PC上的可视化和控制应用迅速增长。在过去几年里，标准化的自动化软件开发的一个主要努力方向就是，通过大量不同总线系统、协议、接口访问自动化设备上的数据。由于人机界面(HMI)、监控和数据采集(SCADA)软件供应商有类似的问题，OPC基金会成立了。该工作小组的目标是基于windows系统，定义一个设备驱动访问自动化数据的即插即用标准。OPC是定义来自不同制造商的设备之间的数据通信的标准。很快,1996年8月，OPC DA(数据访问) 规范发布了。几乎所有提供工业自动化系统的厂商都成为了OPC 基金会的成员。OPC基金会能够比其他组织块的多地定义、通过、实践相关标准。取得这样的成功的一个原因是:削减主要特性和限定API的定义使用微软Windows的COM和DCOM技术。集中关注重要特性，使用基于Windos技术，让已经提出的与用例相关的标准得以快速通过。打破壁垒的OPC UA随着OPC在数以千计的产品中顺利采用，今天的OPC已经作为自动化系统之间的标准接口而应用在自动化金字塔的不同层次上，它甚至用在很多不是预先设计的领域，还有许多其他领域制造商希望利用这样一个OPC标准，但却不能使用，因为OPC的COM依赖性和它使用DCOM的远程访问的局限性。除了对Windows平台的独立性问题，OPC的会员公司还提出了公开复杂的数据和复杂的系统的需求，以消除经典OPC的局限性。OPC UA的诞生是希望为所有现有的基于COM的规范，建立一个没有损失任何功能和性能的真正替代品。此外，它必须满足能够描述复杂系统的丰富的和可扩展的建模能力，以及平台独立的系统接口的任何需求。OPC的广泛应用要求提供从嵌入式系统跨越SCADA和DCS到MES和ERP系统的延展性。OPC UA是在工业自动化场景中使用的基于客户端/服务器的点对点通信协议。它提供用于遥测数据，命令和控制，历史数据，警报和事件日志的API。还有更多。OPC UA也是OPC DA（AE，HD等）的后继产品，与基于COM / DCOM的较旧版本相比，它更加强调互操作性。它不仅提供了平台中立的通信层，并在其中内置了安全性，而且还提供了一组丰富的接口来处理遥测数据，警报和事件，历史数据等。OPC显然具有工业背景，因为它来自过程控制，PLC，SCADA之类的系统领域。也称为IEC 62541。从MQTT的角度看OPC UA可能会问，为什么我们需要OPC UA？MQTT提供了一个完全未定义的主题结构和数据类型，而OPC UA提供了一个用于标准和自定义数据类型的框架，一个已定义（分层）名称空间和一个用于请求/响应样式通信模式的定义。特别是类型系统，即使是简单类型，也是对MQTT的BLOB方法的真正改进。使用MQTT，您将永远不知道消息的内容。它可以是编码为字符串的数字值，JSON编码的对象甚至是猫的图片。另一面的OPC UA确实为您提供了一个类型系统，其中包含有关类型的信息以及实际值。OPC UA的订阅模型还提供了一种非常有效的方式来生动地传输数据，但是仅在客户端和服务器定义的必要时才传输数据。与二进制协议结合使用，可以使真正的资源更加安全。Eclipse Milo本文将引导您完成基于Eclipse Milo创建OPC UA解决方案的第一步。OPC UA，也称为IEC 62541，是用于连接工业自动化系统的IoT解决方案。Eclipse Milo?是基于Java的开源实现。Milo是OPC UA的开源实现。它包括一个高性能堆栈(通道、序列化、数据结构、安全性)以及在堆栈顶部构建的客户端和服务端SDK。官方网站: https://projects.eclipse.org/projects/iot.miloGitHub地址: https://github.com/eclipse/milo传统上，OPC UA框架分为“堆栈”和“ SDK”。“堆栈”是核心通信协议的实现。尽管“ SDK”是基于此构建的，但它提供了一个更简单的应用程序开发模型。Eclipse Milo为“客户端”和“服务器”提供了“堆栈”和“ SDK”。“核心”是客户端和服务器之间共享的通用代码。这应该解释在Maven Central上搜索“ org.eclipse.milo”时Milo的模块结构：org.eclipse.milo : stack-core org.eclipse.milo : stack-client org.eclipse.milo : stack-server org.eclipse.milo : sdk-core org.eclipse.milo : sdk-client org.eclipse.milo : sd…

管理心得，不间断记录
type: item
date: 2022-09-18T18:17:00+08:00
description: 兼职管理1、响应时间 微信响应时间 超过5分钟 2次 中止合作2、培养能力 经验、工具3、收益高于预期4、工程师和质量关于裁员裁员名单是根据个人在公司工作期间对代码的贡献来制定和排名的。高效工作总结：0、必胜信心1、结果导向2、完成时间3、物理专注公司管理思路：互相投资、互相信任，非传统主雇关系1、培养人，把能力传授给下面的人2、放权3、分享机制小团队项目组基本管理：1、放手，新问题主动处理、老问题交给下属处理，借此制定标准处理问题流程化；2、榜样，有困难主动承担、有问题主动冲锋；3、让功让利，向上让功、向下让利；温和派领导人管理思路：1、立功，对公司有贡献；2、握权，能够影响员工收入组成40%、考核评分、项目奖金；3、守信，不轻易承诺、一旦承诺必须兑现；4、立标杆，培养典型员工进步并树立标杆；团队凝聚力1、身先士卒，带动员工积极性；2、知人善任，用人长处；3、勇于背锅；4、尊重、感谢，公约机制；提高员工工作效率1、责任到人；2、限定时间；3、确定标准；4、重复一次；5、检查机制；6、验收考核；老版轻松X成就感V想明白，布置下去1、会算账，不算公司赚多少钱、算员工能赚多少钱；2、会画饼，公司壮大时候做到位置、发展前景；3、会激发，你是专家我不行、顶梁柱；

涉密信息管理系统(分级保护评测)
type: item
date: 2022-09-11T23:34:00+08:00
description: 主要包括两个部分：三员和密级，其他的包括标准的漏扫等三员包括：服务器、数据库、应用系统涉密机东方通中间件、达梦数据库只能安装在root创建user用户，限制文件夹权限服务器三员：中孚数据库三员：达梦DM8 SYSDBA、SYSSSO、SYSAUDITOR(SYS、CTISYS)应用系统三员包括：SYSADMIN 系统管理员 简称：管理员SYSSSO 安全保密管理员 简称：保密员SYSAUDITOR 安全审计员 简称：审计员SYSADMIN：创建、编辑、删除用户创建、编辑、删除角色创建、编辑、删除表单、流程等业务数据，包括数据字典、菜单等SYSSSO：重置、修改用户密码权限角色设置用户日志、管理员日志、审计员日志审计策略SYSAUDITOR：管理员日志、保密员日志，日志内如除了基本的时间、地点、API地址、业务描述，还需要业务数据应用系统密级设定内容：用户密级设定表单密级设定、表单附件密级设定密级优先级设定：人员密级>=信息密级，具体如下发起人>=表单>=附件接收人>=表单>=附件应用系统设置其他要求：Session 10分钟 用户重新登录密码复杂度要求附件存储于服务器指定用户目录默认用户无权限，需要保密员授权用户登录失败次数锁定(含日志)、保密员重置解锁

公司软件工程师设备记录
type: item
date: 2022-06-05T13:51:00+08:00
description: 最近不少新员工入职，规范了一下相关设备，以个人使用经验为主，不定期更新1、开发相关笔电：Thinkpad X1 4TH + ， I7、16G、1T SSD (3min20s)Thinkpad T14 Gen3 ， I5 1240P、64G、1T SSD (47s)扩展坞：Thinkpad OneLink+Thinkpad 40AC台电：Lenovo LEGION 刃9000K（I7、32G、1T SSD、4T HD 、RTX3080 不准游戏）显示器：Dell U2518DR OR 2520DR (2K分辨率最佳2518DR 没有之一)Dell U2717D键盘：Acer OKR140（便宜、手感不输Filco）K6O 红轴鼠标：Logi M590 OR Master 2S（静音）鼠标垫：Steelseries 4D OR 9D（硬脂）屏幕灯：倍思挂灯（便宜）电脑包：Samsonite Kombi 4（2周差完美）电脑椅：Haworth zody 低配（不带锁止）VPN：软件公司VPN必备NAS：Lenovo T2（2*4T红盘）2、生活相关空气净化器：海尔A180A电扇：骆驼空气循环扇冰箱：新飞跑步机：小米米家走步机3、数码相关音频：Sony 300A、N3AP、4.4M12NB1书架：Vintage KEF Q10*2掌机：Nintendo Switch（日版）、Sports、马8豪、Joy-Con*2、健身环、雪人等4、运动相关羽毛球拍：YONEX ASTROX 99Pro、VICTOR 98K、VICTOR BRS-12-4U

软件架构师应该知道的97件事之概括
type: item
date: 2022-05-15T21:49:00+08:00
description: 架构师是一种神秘的职位，据说每个架构师都有密不可传的方法，当然我们不信，更多的是只可意会不可言传。就是说了我们也不会懂，因为还每到“火候”。所能做的就是，当我们到这种火候的时候我们能想起来曾经有过架构师这么说过，然后我们就可以更自信的向前大步走....1、客户需求重于个人简历要想拥有漂亮的个人简历：我们常常向客户推荐技术、手段，甚至方法论来解决问题，使用时髦的编程技巧和流行的范式，有时候根本不是寻求解决问题的最佳方案。积累一批满意的客户，选择切合实际的技术解决他们的难题，让他们乐于推荐你才是最好的履历。2、简化根本复杂性，消除偶发复杂性根本复杂性指的是与生俱来的、无法避免的困难。比如，协调全国的空中交通就是一个“天生的”复杂问题，必须实时跟踪每架飞机的位置。偶发复杂性：是人们解决根本复杂性的过程中衍生的。架构师的责任在于解决问题的根本复杂性，同时避免引入偶发复杂性。怎么做？尽量选择源自实际项目的框架，警惕那些象牙塔里面的产品。3、关键问题可能不是出在技术上简单的项目也会翻船，而且这不是个别情况。大多数项目是人完成的，人才是项目成败与否的基础。如果团队里有人工作方式不正确，拖项目后腿怎么办？有一种非常古老但很完善的技术可以帮助你解决问题。它可能是人类历史上最重要的技术创新，这就是对话。有几个简单的对话技巧可以显著改善对话效果：不要把对话当成对抗。不要带着情绪与人沟通。尝试通过沟通设置共同的目标。4、以沟通为中心，坚持简明清晰的表达方式和开明的领导风格沟通必须简明清晰，没有人愿意阅读冗长的架构决策文档，架构师言简意赅的表达观点是项目成功的必要条件。架构师往往忽略了自己也是领导者。作为领导者我们必须获得同伴的尊敬才能顺利开展工作。所有的成员都希望有明确的沟通和开明的领导。只能这样才能改善沟通效果，建立团结健康的工作环境。5、架构决定性能大家似乎理解，事实并未如此，有些架构师认为简单的更换底层架构就足以解决应用的性能问题，他们很可能轻信了“经测试产品性能超出竞争对手25%”，比如从4ms到3ms，这1ms放在一个性能极低的架构里几乎可以忽略不计。归根结底，所有产品和架构必须遵循分布式计算和物理学的基本原理：运行应用和产品的计算机性能有限，通过物理连接和逻辑协议实现的通信必然有延时。因此，应该承认架构才是影响应用性能和可伸缩性的决定因素。性能参数是无法简单的通过更换软件，或者“调优”底层软件架构来改善的，我们必须在架构的设计和重新设计上投入更多的精力。6、分析客户需求背后的意义顾客和最终用户通常提出的所谓需求，只是他们心目中可行的解决方案，并不是问题唯一的解决途径，当了解顾客的需求背后的意义，我们可以为顾客解决真正的问题并可能降低难度。7、起立发言许多架构师都是从技术岗位上成长起来的，他们擅长和机器打交道，然而架构师更需要与人打交道，无论劝说开发人员接受具体的设计模式，还是向管理层解释购买中间件的利弊，沟通都是达成目标的核心技能。有经验的架构师会很重视推销自己的想法也明白有效沟通的重要性，其中一个简单又实用的技巧是在2人以上的场合发表意见时请“站起来”，起立发言非常重要尤其是当其他人坐着的时候。当你站起来的时候无形中添加一种权威和自信，自然就控制住了场面，听众不会随意打断你的发言，这些都会让你的发言效果大为改观，你会发现站立可以更好的用双手和肢体语言。在10人以上的场合，起立发言方便你与每位听众保持视线接触。眼神交流、肢体语言等表达方式在沟通中的作用不可小觑。起立发言还可以让你更好的控制语气、语调、语速和嗓门，让你的声音传的更远。当你讲到重点内容时，注意放慢语速。发声技巧也能显著改善沟通效果。比沟通事半功倍，起立发言是最简单、有效的方法。8、故障终究会发生硬件会出错，于是我们增加冗余资源来提升系统的可靠性，同时也增加了至少有一台设备出错的概率。软件会出错，增加额外的监控程序也会出错。于是我们又为自动化增加监控，结果是更多的软件，导致更高的故障率。类似的如：三里岛核电站泄漏事故既然必然会出错就需要事先设计好防范故障的模型，以应对威胁系统安全的意外情况。9、我们常常忽略自己在谈判我们都面临过削减预算的要求，如果资金运转促襟见肘，技术方案只能委屈求全。比如如下情景：“我们真的需要这东西吗？”项目投资人发难道。尽管真的需要，我们通常也不能这么回答，因为此时我们是在谈判，此时我们需要认清自己的角色，不能把自己当成工程师，而且投资人明白他在和你谈判，我们应该这样回答"真的需要吗"这类问题：“单台服务器每天至少崩溃3次，没有第二台我们甚至无法跟董事会演示，事实上我们需要4台服务器，构成2组，这样在需要时断开一组而不必被迫关闭系统。即使有一台出现意外，也不影响系统正常运行”10、量化需求速度快不能算作需求，响应灵敏和可扩展也不能算需求，因为我们无法客观…

安全可靠技术和产业联盟-会员单位介绍（2018）
type: item
date: 2022-05-05T10:53:00+08:00
description: 安可联盟，全称是“安全可靠技术和产业联盟”，它的前身是“信息技术应用创新工作委员会”。2016年3月4日工委会成立，是由24家从事软硬件关键技术研究、应用和服务的单位发起建立的非营利性社会组织。2019年1月9日起，安全可靠技术和产业联盟正式变更为中国电子工业标准化技术协会安全可靠工作委员会（后文简称“安全可靠工作委员会”）。这个是官网地址：信息技术应用创新工作委员会安全可靠技术和产业联盟主要成员单位包括联盟理事和联盟会员两大类。安可理事会主要由四类单位：集成厂商、互利网厂商、第三方机构、高等院校，他们主要负责审核后续加入的安可成员单位资质，制定安可标准规范。其中联盟理事（19家）又分为：集成厂商（10家）、测试厂商（4家）、互联网厂商（3家）和高等院校（2家）四大类。集成厂商（10家）包括：华宇软件、神州航天软件、东华软件、东软集团、航天信息、浪潮软件集团、神州信息、太极股份、同方股份、中国软件测试机构（4家）包括：国家工业信息安全发展研究中心、中国电子技术标准化研究院、工业和信息化部电子第五研究所、中国电子信息产业发展研究院互联网厂商（3家）包括：阿里云、金山软件、华为技术高等院校（2家）包括：北京航空航天大学、北京理工大学联盟会员则包含：芯片厂商（7家）、集成厂商（12家）、整机厂商（8家）、操作系统厂商（9家）、数据库厂商（6家）、中间件厂商（3家）、流版签厂商（7家）、外设固件厂商（3家）、安全厂商（6家）、网络厂商（3家）、互联网厂商（2家）、存储厂商（5家）和应用软件厂商（2家）共十二大类。芯片厂商（7家）包括：上海兆芯（X86）、东土军悦（交换机芯片、东土科技）、国科微（安防、存储、物联网芯片）、盛科网络（交换机芯片、中国电子、振华科技）、天津飞腾（ARM、中国长城、振华科技）、上海高性能集成电路设计中心（Alpha、申威）、龙芯中科（MIPS）集成厂商（12家）包括：百得科技、华胜天成、中软信息（中国软件）、广东省信息工程公司、中科软、南威软件、太极信息（太极股份）、烽火信息（烽火通信）、万达信息、中软系统（中国软件）、中科九洲、长城软件（中国软件）整机厂商（8家）包括：上海仪电智通、联想长风、华胜天成、长城科技（中国长城）、宝德网络、曙光信息（中科曙光）、百信信息、北京计算机技术及应用研究所（航天二院706所）操作系统厂商（9家）包括：中科方德（兆芯）、一铭软件、湖南麒麟信安（中国软件）、天津麒麟（中国软件）、思普投资（X86）、深之度、普华基础软件（中国电科）、航天国盛（航天科技）、中标软件（中国软件）数据库厂商（6家）包括：武汉达梦（中国软件）、神舟通用（航天科技）、人大金仓（太极股份）、南大通用、恒辉信达、瀚高基础软件中间件厂商（3家）包括：金蝶天燕中间件、东方通、中创软件流版签厂商（7家）包括：金格科技（电子签章）、方正国际软件（电子文档）、书生电子（启明星辰、安全文档）、数科网维（版式OFD）、航天福昕（文档OFD）、安证通（电子签章）、永中软件（office，办公软件）外设固件厂商（3家）包括：立思辰（文件管理）、中电科技（中国电子、BIOS等）、光电通信（传真机）安全厂商（6家）包括：星网锐捷（通信、安全）、中孚信息（安全保密）、安宁创新（邮件、消息）、中安网脉（密码、存储）、海泰方圆（密码、安全）、卫士通（密码、芯片、系统）网络厂商（3家）包括：紫光集团（从芯到云）、迈普通信（中国电子、网络设备）、仰联信通（交换机）互联网厂商（2家）包括：拓尔思、恒生电子存储厂商（5家）包括：滕凌科技（存储）、亚细亚智业（存储灾备）、同有科技（存储）、鲸鲨软件（存储）、鼎甲科技（中国电子、灾备）应用软件厂商（2家）包括：慧点科技（太极股份、管理软件）、华电园技术（办公自动化）来源时间 2018-07

7大迹象，表明你的DevOps 做对了！
type: item
date: 2022-03-08T16:20:15+08:00
description: 据预测，未来 10 年中，企业或组织的数字化转型会达到高峰，将比过去几十年的总和还要多。而这一进程，开发工程师必须找到更加有效的开发方式，才能实现。在这一层面来说，DevOps 是数字业务转型计划的核心。目前，企业越来越重视DevOps，并开始向这种开发方式转型。但是，如此多声称专注于 DevOps 的企业或组织，真的都做对了吗？在大多数的 DevOps 实践中，仅仅涉及到了特定工具的使用，企业非常松散地遵循着某些 DevOps 原则。然而，要想真正成为一个以 DevOps 为中心的组织，这些远远不够。参照以下 7 点，或许能够帮助你及时纠偏：一、部署是完全自动化的每一个项目工程通常都包含了很多的代码文件、配置文件、第三方文件、图片、样式文件等不同部分，要想将这些部分有效组装、最终形成最后的应用结果，往往需要借助构建工具或策略。构建过程如果仅仅依赖人工，就会十分繁琐。于是，自动化构建、自动化发布、自动化部署的想法和探索就浮现了。自动化的出现，将大大提升工作效率。在 DevOps 实践中，是需要从头到尾完全自动化部署的。自动部署的意义不仅仅在于节省时间，更多是避免问题的出现，手动部署更常出现因为人为错误引起的问题，而自动部署可以在问题出现时迅速恢复到以前的版本。二、有频繁且快速的发布周期天下武功唯快不破。想要获得更强大的竞争力，只有不断部署和快速修复。DevOps 中一个核心功能就是 CI/CD（持续集成/持续交付），寻找更有效的自动化和部署更新迭代的方法，让开发人员提高生产效率、并快速地发布到生产环境中。CI/CD 通过在构建、测试和部署应用程序时强制自动化完成。这种 DevOps 方法的精髓在于：1）通过频繁的代码库提交、自动化构建等来提高生产力；2）通过集成自动化测试以及开发期间的测试，增加在开发早期发现错误的机会；3）得益于频繁的测试和自动化部署系统，可以更快地发布版本。三、注重可观察性国外的一份报告显示，可观察性正在成为 DevOps 实践中绝对不能缺少的一环。在跨越多个流程的数字业务转型中，可观察性有非常重要的意义。New Relic 对 1300 名 IT 领导者、软件工程师和开发人员进行的一项全球调查发现，90% 的受访者认为可观察性对业务至关重要。只有更多地基于事实而非直觉，才能作出明智的决策，越来越多的团队开始从整个企业应用程序环境中收集数据，来提高整个开发过程的可观察性，可观察性也在生产前和生产后的环境中扮演越来越重要的角色。四、有持续的反馈循环初期，DevOpsDays 活动的发起人和 DevOps 这个词的创始人 Patrick Debois 发现，有关 DevOps 的话题相互交织在一起形成了四个不同的反馈环，如上图所示。其中，蓝色气泡代表技术，黄色气泡代表过程管理。一起形成了 4 个循环。开发-测试反馈环（黑色箭头反馈环）；开发-运维反馈环（绿色箭头反馈环）；业务-运维反馈环（红色箭头反馈环）；业务-用户反馈环（紫色箭头反馈环）。在现在的 DevOps 理念中，出现错误并不可怕，可怕的是没有一个持续的反馈循环系统来检测何时何地出现问题。反馈循环需要在发生错误时快速通知，从而使问题得到更快地解决。很多时候，我们遇到问题仅仅是简单地解决了它，并没有花时间分析问题发生的原因以及如何防止问题再次出现。这样的循环是不完整的。从某种程度上，如果你设置了一个系统来识别问题、修复问题和改进问题，还需要认真分析，才意味着你在正确地实践 DevOps。具体来说，一个监控系统需要观察并记录系统状态变化和数据的流程：1）状态的变化：可以通过状态的直接度量或者更新日志来表示；2）数据：可以通过记录内部组件和外部系统之间的请求和响应来记录。五、开发和运营团队一起工作Dev（开发） 和 Ops（运维） 的矛盾主要是面向适应性的敏捷软件交付和面向经验性的传统运维之间的矛盾。这个矛盾最先由 John Allspaw 和 Paul Hammond 在“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”提出，并以“Cooperation”作为整个演讲的核心，讲述了他们解决这个矛盾的实践经验。在一个组织中，如果相关利益者的利益不一致，在既定流程的进行中一定会碰到诸多阻力。而在这一点上，首先做的就是把 Dev 和 Ops 的利益一致化，从而减少 Ops 对软件交付的阻力。在传统观念中，开发的工作是增添新的功能，而运维的工作则是保证站点的稳定和高性能。 而在 DevOps 的观念中，Ops 的工作目标应该是激活业务（enable the business ），与 Dev 是一致的。至此，DevOps 众所周知的主要好处就是打破开发和运营之间的孤岛。在维基百科上，DevOps 的解释也…

新项目别一上来就用微服务
type: item
date: 2022-02-13T14:17:33+08:00
description: 微服务变得越来越理所当然，似乎我们一直生活在微服务的世界中。很多时候，我们常常讨论微服务采用与否、如何选型等问题。但本文作者 Arnold Galovics 想讨论的是，为什么一个全新的项目从开始就使用微服务通常是个坏主意。很长一段时间以来，他都在思考这个问题。最近，当他与其他开发人员交谈并询问他们如何启动一个全新项目时，答案几乎都是：这儿用一个微服务，那儿用一个微服务，用户管理用一个微服务，身份验证用一个微服务，鉴权用一个微服务，session 管理用一个微服务等等。因此，关于微服务，Arnold 想基于他过去工作项目的一手经验，讲讲别人没有讲过的一些东西，他撰写了一篇题为《不要从微服务开始，单体架构才是你的朋友》（Don’t Start With Microservices – Monoliths Are Your Friend）的文章。Arnold 的文章很快在技术社区引发热议。有持赞同意见的人直言，微服务对于大多数普通需求来说是一种“矫枉过正”，还有人提出微服务有个 Arnold 没提到的更严重的缺点——将事情分成模块需要时间，并且涉及做出我们可能不知道答案的决定。“启动新产品时，最重要的是尽快启动并运行产品，以便人们可以试用并提供反馈。而根据收到的反馈，我们往往可能会意识到需要构建与现有的完全不同的东西。我见过很多工程劣质的成功产品，也见过很多设计精良的产品失败。产品的成功与其设计的好坏无关。速度往往是最重要的因素。”另外，有条热门评论提出了个有意思的问题：为什么没有人谈论介于这两者之间的架构——模块化单体？对此，有回复说道“因为没有新发明的架构称为‘模块化单体’——单体从一开始就应该是模块化的。”该回复进一步指出，微服务不是单体应用不好而诞生的答案，人们的理解在某些地方出现了问题，这也可能是因为很多人不知道应该在代码中构建模块，然后大量的单体最终成为“意大利面条式”代码，就像现在许多微服务架构那样。有人对此表示赞同并表示，“模块化单体”只是“代码中关注点的适当分离”，其实从一开始就存在。但也有人提出反对意见，认为“模块化单体”要比“分离关注点”要更复杂，并不完全是一回事。一千个人眼中有一千个哈姆雷特，我们将 Arnold Galovic 的这篇文章翻译出来，希望能为读者带来一些参考价值。以下是他的分享内容：理想中的微服务我们先来看看，多数文章提到的一些微服务的主要优势有哪些：故障隔离消除技术锁定更容易理解更快的部署可伸缩性是的，这些都不是书中的虚假承诺，但我也必须对你说实话，使用微服务的话，你的系统很难实现这些承诺。下面让我一一列举这些优势。故障隔离。由于应用程序由多个服务组成，因此如果其中一个服务宕机或出现问题，则只会影响系统的那个部分。以 Netflix 为例，当你观看节目时，你并不关心推荐。因此，如果它们有一个服务来处理当前观众，为他们提供视频流；它们有另一个服务来处理个人用户推荐。如果推荐服务宕机，系统中最重要的功能（例如观看节目）不会受到影响。故障被隔离了。消除技术锁定。想想单体应用。它是一个巨大的应用程序，有成百上千个 API，管理数百个数据库表。这个应用程序是用 Java 写的，团队花了 5 年时间开发它。一种奇特的新语言出现了，纸面上带来更好的性能、提供更好的安全性等等。这可能是 Go 或 Rust，团队想试验下该语言及其技术栈。他们如何在一个单体应用中做到这一点呢？他们做不到，因为这是一个单独的部署包。你可以将应用程序的一部分切换到不同的语言，但这并不容易做到。使用微服务时，不同的服务可以使用不同的技术栈。服务 A 可以用 Java 写，服务 B 可以用 Go 写，服务 C 可以用Whitespace写，如果你有勇气这么做的话。更容易理解。当你有多个服务负责整个功能的一小部分时，这个服务本质上会更小，因此更容易理解。更快的部署。在常规的单体应用系统中，要么完全部署，要么根本不部署。你需要部署一个包，这是一个要么全有要么全无的场景。使用微服务，你有机会独立部署，这意味着，如果你想要部署推荐服务的一次升级（回到 Netflix 的例子），你可以部署单个服务并节省大量时间。可伸缩性。我的最爱。你可以通过启动多个实例来增加特定功能的容量，从而扩展服务。像前面举的例子，如果人们在 Netflix 上查看大量推荐，它们可以很容易地启动多个推荐服务的实例来应对负载。在单体应用环境中，你要么扩展应用程序的每一个部分，要么什么都不扩展。现实生活中的微服务我要用残酷的事实打击你，我的朋友。我并不是说这些优势无法实现，但是你、你的项目、你的组织必须非常努力才有可能实现这些优势。基础设施要求下面让我从微服务的一个最大困难——基础设施开始讲起。绝对是 10 r6g 的真实照片。在 K8S 上运行的单个登录应用程序的 16x…