只要利益不发生冲突，别人说话一般不要去反驳。人际交往的高段位技巧，热情大方，一问三不知。你真正要做的事，连神明都不要讲，安静的做成功了再说，是以秘城，言以懈息。努力克制自己的情绪，学会赞美和闭嘴。给别人办事，一定要装的很难办，给领导送礼一定要装的很自然，给爱人花钱，一定要装得很痛快，请别人吃饭，一定要装得很大气，和人谈生意，一定要装得很成功，和人谈感情，一定要装得很纯洁，和人谈工作，一定要装得很专业，不能喝酒时，一定要装得很醉，不能赴约时,一定要装得很失落，不能帮忙时，一定要装的很难过。做人一定要有城府，逢人只说三分话，不可全抛一片心。你要是想看透人心，只需要落魄一次就够了。也为人在落魄的时候，身边的牛鬼蛇神都会露出真实面目。德不配位，财不配身，怎么破，很简单，就是习惯它，升官了，静默半年别折腾，赚钱了，放手里半年不花，就行了。处理问题，包括应急事件，狭路相逢和退一步海阔天空都不可取，通用的是沉默是金和让子弹飞，有奇效。刷视频，多看看打架斗殴、车祸集锦、意外身亡的，危机意识和避险意识会潜移默化。多读历史，人虽然会变得冷漠，但是能够提高生存能力，你死我活才是本质。社会感悟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、与人打交道，心理博弈，让别人舒服； #方法论
前言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 : sdk-server Copy to clipboardErrorCopied连接到现有的OPC UA服务器将只需要您使用“ sdk-client”，因为所有其他模块都是该模块的临时依赖项。同样，创建自己的OPC UA服务器也仅需要“ sdk-server”模块。OPC UA连接一览图
兼职管理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、会激发，你是专家我不行、顶梁柱；
主要包括两个部分：三员和密级，其他的包括标准的漏扫等三员包括：服务器、数据库、应用系统涉密机东方通中间件、达梦数据库只能安装在root创建user用户，限制文件夹权限服务器三员：中孚数据库三员：达梦DM8 SYSDBA、SYSSSO、SYSAUDITOR(SYS、CTISYS)应用系统三员包括：SYSADMIN 系统管理员 简称：管理员SYSSSO 安全保密管理员 简称：保密员SYSAUDITOR 安全审计员 简称：审计员SYSADMIN：创建、编辑、删除用户创建、编辑、删除角色创建、编辑、删除表单、流程等业务数据，包括数据字典、菜单等SYSSSO：重置、修改用户密码权限角色设置用户日志、管理员日志、审计员日志审计策略SYSAUDITOR：管理员日志、保密员日志，日志内如除了基本的时间、地点、API地址、业务描述，还需要业务数据应用系统密级设定内容：用户密级设定表单密级设定、表单附件密级设定密级优先级设定：人员密级>=信息密级，具体如下发起人>=表单>=附件接收人>=表单>=附件应用系统设置其他要求：Session 10分钟 用户重新登录密码复杂度要求附件存储于服务器指定用户目录默认用户无权限，需要保密员授权用户登录失败次数锁定(含日志)、保密员重置解锁
最近不少新员工入职，规范了一下相关设备，以个人使用经验为主，不定期更新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件事之概括
架构师是一种神秘的职位，据说每个架构师都有密不可传的方法，当然我们不信，更多的是只可意会不可言传。就是说了我们也不会懂，因为还每到“火候”。所能做的就是，当我们到这种火候的时候我们能想起来曾经有过架构师这么说过，然后我们就可以更自信的向前大步走....1、客户需求重于个人简历要想拥有漂亮的个人简历：我们常常向客户推荐技术、手段，甚至方法论来解决问题，使用时髦的编程技巧和流行的范式，有时候根本不是寻求解决问题的最佳方案。积累一批满意的客户，选择切合实际的技术解决他们的难题，让他们乐于推荐你才是最好的履历。2、简化根本复杂性，消除偶发复杂性根本复杂性指的是与生俱来的、无法避免的困难。比如，协调全国的空中交通就是一个“天生的”复杂问题，必须实时跟踪每架飞机的位置。偶发复杂性：是人们解决根本复杂性的过程中衍生的。架构师的责任在于解决问题的根本复杂性，同时避免引入偶发复杂性。怎么做？尽量选择源自实际项目的框架，警惕那些象牙塔里面的产品。3、关键问题可能不是出在技术上简单的项目也会翻船，而且这不是个别情况。大多数项目是人完成的，人才是项目成败与否的基础。如果团队里有人工作方式不正确，拖项目后腿怎么办？有一种非常古老但很完善的技术可以帮助你解决问题。它可能是人类历史上最重要的技术创新，这就是对话。有几个简单的对话技巧可以显著改善对话效果：不要把对话当成对抗。不要带着情绪与人沟通。尝试通过沟通设置共同的目标。4、以沟通为中心，坚持简明清晰的表达方式和开明的领导风格沟通必须简明清晰，没有人愿意阅读冗长的架构决策文档，架构师言简意赅的表达观点是项目成功的必要条件。架构师往往忽略了自己也是领导者。作为领导者我们必须获得同伴的尊敬才能顺利开展工作。所有的成员都希望有明确的沟通和开明的领导。只能这样才能改善沟通效果，建立团结健康的工作环境。5、架构决定性能大家似乎理解，事实并未如此，有些架构师认为简单的更换底层架构就足以解决应用的性能问题，他们很可能轻信了“经测试产品性能超出竞争对手25%”，比如从4ms到3ms，这1ms放在一个性能极低的架构里几乎可以忽略不计。归根结底，所有产品和架构必须遵循分布式计算和物理学的基本原理：运行应用和产品的计算机性能有限，通过物理连接和逻辑协议实现的通信必然有延时。因此，应该承认架构才是影响应用性能和可伸缩性的决定因素。性能参数是无法简单的通过更换软件，或者“调优”底层软件架构来改善的，我们必须在架构的设计和重新设计上投入更多的精力。6、分析客户需求背后的意义顾客和最终用户通常提出的所谓需求，只是他们心目中可行的解决方案，并不是问题唯一的解决途径，当了解顾客的需求背后的意义，我们可以为顾客解决真正的问题并可能降低难度。7、起立发言许多架构师都是从技术岗位上成长起来的，他们擅长和机器打交道，然而架构师更需要与人打交道，无论劝说开发人员接受具体的设计模式，还是向管理层解释购买中间件的利弊，沟通都是达成目标的核心技能。有经验的架构师会很重视推销自己的想法也明白有效沟通的重要性，其中一个简单又实用的技巧是在2人以上的场合发表意见时请“站起来”，起立发言非常重要尤其是当其他人坐着的时候。当你站起来的时候无形中添加一种权威和自信，自然就控制住了场面，听众不会随意打断你的发言，这些都会让你的发言效果大为改观，你会发现站立可以更好的用双手和肢体语言。在10人以上的场合，起立发言方便你与每位听众保持视线接触。眼神交流、肢体语言等表达方式在沟通中的作用不可小觑。起立发言还可以让你更好的控制语气、语调、语速和嗓门，让你的声音传的更远。当你讲到重点内容时，注意放慢语速。发声技巧也能显著改善沟通效果。比沟通事半功倍，起立发言是最简单、有效的方法。8、故障终究会发生硬件会出错，于是我们增加冗余资源来提升系统的可靠性，同时也增加了至少有一台设备出错的概率。软件会出错，增加额外的监控程序也会出错。于是我们又为自动化增加监控，结果是更多的软件，导致更高的故障率。类似的如：三里岛核电站泄漏事故既然必然会出错就需要事先设计好防范故障的模型，以应对威胁系统安全的意外情况。9、我们常常忽略自己在谈判我们都面临过削减预算的要求，如果资金运转促襟见肘，技术方案只能委屈求全。比如如下情景：“我们真的需要这东西吗？”项目投资人发难道。尽管真的需要，我们通常也不能这么回答，因为此时我们是在谈判，此时我们需要认清自己的角色，不能把自己当成工程师，而且投资人明白他在和你谈判，我们应该这样回答"真的需要吗"这类问题：“单台服务器每天至少崩溃3次，没有第二台我们甚至无法跟董事会演示，事实上我们需要4台服务器，构成2组，这样在需要时断开一组而不必被迫关闭系统。即使有一台出现意外，也不影响系统正常运行”10、量化需求速度快不能算作需求，响应灵敏和可扩展也不能算需求，因为我们无法客观地判断是否满足了这样的条件。正确的描述需求应该像这样：“必须在1500ms内响应用户的输入。在正常负载下，平均响应时间控制在750ms-1250ms之间。由于用户无法识别500ms以内的响应，所以我们没必要将响应时间降到这个范围一下。”11、一行代码比500行架构说明更有价值架构说明书（specifications）很重要，因为它描述了构建系统的模式，但是静下心来全面彻底地理解架构——即从宏观上把握组件之间的交互，又着眼于组件内部的代码细节——也很重要。架构师往往容易被抽象的架构所吸引，沉迷于设计过程。事实上仅有架构说明书是远远不够的。软件项目的最终目标是建立生产体系，架构师必须时刻关注这个目标，牢记设计只是达到目标的手段，而不是目标。如果亲自开发，应该珍视自己花在写代码上的时间，千万别听信这会分散架构师精力的说法。这样既能拓展你的宏观视野，也能丰富你的微观世界。12、放之四海皆准的解决方案架构师应该坚持培养和训练“情景意识”——因为我们遇到的问题千差万别，不存在放之四海皆准的解决方案。“情景模式”：调查有经验的架构师处理复杂问题的方式。有经验的架构师和设计师的答案如出一辙：只须使用常识....【一个】比“常识”更贴切的说法是“情景意识”——在给定情景下对合理性的把握。架构师通过学习和实践，不断积累的案例和经验，建立足够的情景意识。他们通常需要十年的磨练，才能解决系统层次的问题。13、提前关注性能问题商业用户的需求主要表现卫队功能的要求。系统的非功能特性则由架构师负责，包括：性能表现、灵活性、持续正常工作时间、技术支持资源等。但是对非功能特性的初始测试往往被拖到开发周期的最后阶段，有时还由开发团队来操刀，这样的错误屡见不鲜。在项目周期的最后阶段才关注性能问题，会导致我们错失大量历史信息，这些信息包含性能变化的细节。如果性能是架构设计的重要指标，就应该尽早展开性能测试。在采用敏捷方法开发的项目中，如果有2周为一个迭代周期，我认为性能测试的开始时间最迟不能晚于第三次迭代。坚持技术测试是需要耐心和毅力的，无论是搭建合适的测试环境，采集适当的数据集，还是编写必要的测试用例，都需要投入大量的时间。14、架构设计要平衡兼顾多方需求平衡兼顾各方的要求和项目的技术需求CEO需要控制成本运营部门要求软件易于管理二次开发人员要求软件代码容易学习方便维护业务部门：旅行合同义务、创造收益、树立客户口碑、控制成本，创造有价值的技术资产技术部门：确保软件的功能15、草率提交任务是不负责任的行为傍晚时候，团队正在完成本次迭代的收尾工作，一切按部就班、有条不紊。只有约翰赶着赴约有些急躁，他仓促写完自己的代码，编译、检入，然后匆匆离开。几分钟后红灯亮起（许多采用敏捷开发方法的软件公司（例如ThouthtWorks）在每个团队成员的桌上放置一盏3色灯，用来表示当前的集成状态，黄色正在集成，绿色集成成功，红色集成失败），构建失败。约翰没来得及执行自动测试就草率地提交了任务，连累大家无法继续工作。正常的工作秩序全被打乱了。这个时候架构师就该发挥作用了，营造一种团队文化，以维护流程通畅为重，以浪费他人时间为耻。要做到这一点，务必在系统内实现完善的自动测试功能，纠正开发人员的行为。沉下心来改变系统的生产效率，缩短流程避免各行其是，才能缩短开发时间。总之一定要杜绝一切草率提交任务的念头。16、不要在一棵树上吊死负责构建系统的人似乎无法接受这样的事实：没有哪种数据类型、消息格式、消息传送机制，甚至主流的架构组件、策略、观点用来能够用来解决所有的业务问题，毕竟当大家都希望摆脱业务需求不断滋生的意外和烦恼。才用多钟表现方式、多钟传输方式不是为了消遣。应当认识到，通过分解系统的非功能参数，可以为客户提供多样化的解决方案。17、业务目标至上在商业化的背景下开发企业应用，架构师必须成为业务部门和技术部门沟通的桥梁，周旋调解，兼顾双方利益，同时业务目标来驱动项目 开发。业务目标和实际的开发条件应该成为架构师主持制定决策的参照系统。在启动一个软件项目之前，应当制定计划，明确投资回报的预期。架构师必须把握这个预期，并预估该项目的商业价值，避免做出错误的技术决策，造成经费超支。用业务目标驱动项目开发，才能保证软件开发团队的长远利益。18、先确保解决方案简单可用，再考虑通用性和复用性许多用来实现基础设施的代码，包括组建、框架、类库、基础服务，普遍存在一个问题，它们设计一向强调通用性而不考虑具体应用。如果存在多个可实施方案难以取舍，“先简单后通用”原则可以成为最终的评判标准。虽然很多架构师重视通用性，但这样做是有前提条件的。并非所有人都需要通用性，愿意为它掏钱。19、架构师应该亲力亲为称职的架构师应该通过示范领导团队，架构师通常都取得过不错的业绩，有份出彩的简历，容易获得业务人员和技术人员的青睐。但除非他能展示自己的实践能力，否则很难赢得团队的尊重，团队成员将无法从他身上学到东西，大家甚至难以在他的领导下做好本职工作。20、持续集成架构师（无论是应用架构师还是企业架构师）都应该在项目中鼓励推广持续集成的方法和工具。现在持续集成已经取代了“尽早构建，经常构建”（build early and often）的提法，它确保当前的开发不会出现意外，是一种降低风险的技巧。构建应用程序是持续集成最主要的内容，它通常是自动执行的，可以设置在夜里执行，或者当源代码改变时自动触发。当然你也可以选择手动构建。21、避免进度调整失误导致项目失败的原因很多，最常见的是中途临时调整进度。改变计划回答带来以下问题：仓促的进度会导致拙略的设计、蹩脚的文档，可能引发质量问题，导致用户拒绝签收仓促完成代码导致bug增多，测试不充分增加测试中可能出现的问题以上问题均能引发产品质量问题，而解决产品质量的问题代价更高。最后的结果是成本不降反升，通常项目就是这样失败的。22、取舍的艺术架构师应该明白鱼和熊掌不可兼得的道理。如果2个性能本身就是冲突的，满足一项就会导致另一项失败或者整体失败。23、打造数据库堡垒创建牢固的数据模型要从第一天开始牢固的数据模型既可以保障当前的数据的安全，又为今后提供可扩展性。要保障数据安全就必须隔离来自应用层的bug（在不断变化的应用层中这些bug无处不在，不会因为你的勤奋而消失），必须严格遵守引用完整性规则，尽量使用域约束规则，还要选择恰当的键，即保证数据的完整性，又遵守约束规则。要实现可扩展性，就必须正确地将数据标准化。以便今后在数据模型上添加架构层：千万不要偷懒走捷径。为了妥善保护数据库必须拒绝无效数据，阻止无意义的关系。在定义键、外键、域约束时，应该采取简洁的容易被理解和验证的名称，使他们含义不言自明。数据模型中的域规则也要做到物理化和持久化，避免他们在应用逻辑发生改变时被删除。为了充分发挥关系型数据库的作用——让它真正的成为应用的一部分，而不仅仅是存放数据的库房——必须从开始构建数据库时，就深刻理解业务需求。随着产品的演变，数据层也会发生变化。24、重视不确定性当你面临2中选择的时候应该仔细考虑设计中的不确定性。迫于压力，人们常常为了决策而决策。这时可以借鉴期权思想（指在期货交易中，权利的受让可以在将来的某个约定的时间，根据当时的情况决定是否行使权利，即推迟做决定时间），当你在不同的系统开发路线之间举棋不定时，不要急于做出决策。推迟决策，直到掌握更详实的信息，以便做出更可靠的决策。但也别太迟，要赶在这些信息失效前利用他们。25、不要轻易放过不起眼的问题问题出现时，虽然个别团队成员会发现一些端倪，但往往由于大多数人认识不到其严重性，这些问题不是被忽略就是被搁置，知道变得难以解决。注意造成的原因和哪些方法克服这些消极因素。26、让大家学会复用有这样一种观点，认为设计优良的框架、细致考虑并精巧实现的架构自然会被人们重复利用。但也是在满足下列条件下擦可能被复用：大家都知道它的存在大家知道如何使用它们大家认识到利用已有资源好过自己动手27、架构里面没有大写“I"英文单词架构（architecture）里面有字母”i"但不是大写的“I”。它代表的不是那个喜欢唤起别人关注，喜欢凌驾于众人之上的“I"(自我）。自我可能是我们这最大的敌人。如何避免犯错误？需求不会撒谎。重视团队合作。检查你的工作。自我反省。28、使用”一千英尺高“的视图用来了解正在开发的软件质量如何在架构图中，系统是由若干个小方框组成的，方框之间的连线代表着各种含义：依赖关系、数据流、共享资源等。这种图好比从飞机上俯瞰地面上的风景，我们称之为“三万英尺高”的视图。另一种典型的视图是源代码，好比占在地面上看大地。两种视图都无法冲分钟展现软件的质量：前者太抽象，而后者细节太多，以至于我们看不清整个架构。很显然我们需要一个介于2着之间的视图——“一千英尺高”的视图。"一千英尺高“的视图提供的信息来自恰当的层次，囊括大量数据和多钟度量标准，例如方法数，类扇出数和圈复杂度。具体的视图与特定的质量属性密切相关。一旦我们绘制出合适的视图，判断软件质量就更客观了。29、先尝试后决策创建一个应用需要作出很多决策。有些决策设计挑选框架和函数，而另一些则需要选定特定的设计模式。架构师应该持续关注那些马上要制定的决策，架构师可以在决策之前，要求几个开发人员商量解决方案，比较不同解决方案的优点和弊端。对同一个问题尝试2种或者2种以上的解决方案，可能是代价最低的选择。事后发现方案不合适或者是没人发现方案不合适都是糟糕的情况。30、掌握业务领域知识高水平的软件架构师不仅要懂技术，还要掌握问题空间对应的业务领域的知识。缺乏业务领域知识的架构师不能顺利地解决问题，无法把握业务目标和业务需求，也就难以设计有效的架构来满足需求。31、程序设计师一种设计程序设计属于设计范畴而不是生产范畴。软件的生产则是自动化的，由编译器、构建工具和测试代码共同完成。如果把编写代码看成设计行为，而不是生产行为，我们就能采用一些已经被证明有效的管理方式。这些方法过去用于管理不可预测性的创新工作，比如研发新车、新药、新的电脑游戏。我们指的是敏捷的产品管理方法和精益生产方法，比如SCRUM。32、让开发人员自己做主多数架构师都是从开发人员干起的。以前作为开发人员你很少有机会仔细观察整个系统是怎样组合在一起的，而作为架构师这是你工作的重点。如果想出色的完成工作，是不可能有空闲去干预开发人员的。33、时间改变一切选择值得投入精力的工作简单原则，回顾以前或者更早的项目时，几乎都会惊诧自己当初的做法，如果有机会再做一次，我们一定会以更简单点的方法来完成。这就是时间的作用。别跟以前的工作过不去，你现在看重的设计思路，可能2-3年后就会被自己否定。34、设立软件架构专业为时尚早设计软件架构师一门手艺，从业者无意要通过实践和训练才能在这个领域获得成功。35、控制项目规模估算与准确的科学计算相差甚远，所以产品特性实现起来常常比预期要困难。缩小和控制项目规模策略：抓住真正需求。分而治之，设置优先级，尽快交付。敏捷方法的倡导者提倡开发”最简单有用的东西“，越复杂的架构越难以实现。缩小项目规模通常会降低架构的复杂性，这是架构师提高成功几率最有效的途径。36、架构师不是演员，是管家架构师接受新项目，都渴望证明自己的价值，这是人之常情。炫耀和作秀与指挥开发项目背道而驰。架构师的职责和管家类似，承担着管理他人资产的责任。架构师要满足不同领域的客户需求，而这些领域的专业知识通常是架构师所不具备的。37、软件架构的道德责任软件世界的道德范畴边界并不清晰，尽管有些行为无疑是不道德的，比如侵犯他人的公民权利等，但还有些行为的道德意义不被察觉，比如浪费别人的时间。架构师的每项决策（例如设置必填项和规定流程），都限制了用户可以做什么不能做什么。这比法律容易的多，并且还找不到法院受理他们的诉讼。我们可以从倍增效应的角度来看待软件的影响。软件问题所造成的损失将以成不可估量的倍数出现，尤其是给人心理上的。假设架构师要实现一个新功能，简单的设计要1天完成复杂的设计要1周的时间，但简单的设计要强迫用户输入大量的数据，这个过程常常会丢失数据，耽搁工作，让人非常沮丧。从长远看浪费别人的时间将远远超过你省下的时间。损人利己是不道德的行为哪怕程度很轻。38、摩天大厦不可伸缩土木工程不只是设计建筑这么简单，真正的难题在于规划整个施工过程，确保建筑物拔地而起，包括从奠基到竣工的所有工作。其中有很多经验值得我们借鉴，尤其是对于部署大型集成化软件系统（包括所有企业应用和web应用）。如果把软件比喻成土木工程，那么传统的大爆炸式软件部署方式就好比把备齐的建筑材料一股脑仍上天，指望他们瞬间拼成一座大厦一样那么可笑。相反，无论是开发新项目，还是替换已有的系统，都应该逐个部署系统组件。2个优点：首先，隐藏在代码中的技术风险是部署软件时无法回避的问题，其次这种方法迫使我们设计清晰的组件间接口。有些是不能借鉴的，尤其是在建筑工程中屡试不爽的”瀑布式“施工方法。毕竟摩天大厦不需要可伸缩性。应用软件只要具备了用户要求的功能便可发布，不用等到十全十美。事实上，产品越早发布公司的净收益就越高。这样既可增加商业利润又可以改变架构品质，这样实用的技巧实在不多。39、混合开发的时代已经来临混合编程：在一套软件系统中同时采用多种核心编程语言现在可以采用基于文本协议（text-based protocols）了。这些新技术以特定格式的文本作为载体，便于所有人编写和理解，为混合开发提供了前所未有的可能性。架构师把若干个强大的开发工具组合起来使用，以往的标准是挑选合适的编程语言，现在则演变成挑选合适的编程范式。选择多了并不总是好事，但至少好过以往软件架构非此即彼的窘境。40、性能至上性能指标和其他指标一样重要。有些设计师把性能放到最后考虑。我们通常把系统响应用户输入的时间作为衡量性能的标准。生产率通常用来描述构架系统的效率，也属于性能范畴，其重要性在于直接影响项目的成本和进度。系统的人机交互性能直接关系到用户是否愿意掏钱。包括：响应时间，是否直观，操作步骤是否简单。合格的说明书除了注明系统每秒钟的响应次数，还要测量典型的任务时间。非交互性组件的性能同样影响着系统的表现。在考虑系统的实现方法和运维策略时，架构师和设计师应该密切的关注系统的性能表现。41、留意架构图里面的空白区域软件系统由相互依赖的程序组成，我们把装配这些程序的方法及程序之间的关系成为架构。假设某个箭头表示”使用HTTP协议，发送SOAP-XML格式的同步请求/响应消息“，由于架构图里面的空间有限，写不了这么多内容，所以通常用简单的注释表示。从技术角度出发可以简写成”XML over HTTP",如果从业务角度出发，有可能写成“查询库存单元”。不同的程序看似通过箭头直接联系，其实不然，矩形之间的空白区域充满 着各种软件和硬件。应该理解每个箭头包含的静态信息和动态信息。42、学习软件专业的行话每个专业都有行话，同行之间讲行话方便交流，清晰、简洁、高效的方式与同行进行沟通，是软件架构师应具备的能力。架构师必须掌握基本的架构模式和设计模式，学会辨别不同模式，并借助他们和同行及开发人员进行交流。架构和设计模式可以分为四大类：企业架构模式、应用架构模式、集成模式、设计模式。企业架构模式定义架构的全局框架结构。应用架构模式指出了全局架构下的子系统及局部应用的设计方法。设计模式研究架构中各个组件的构造方法。除以上4种外，架构师还应该了解和提防各种反模式。反模式：影响软件开发中的常见错误：需求分析麻痹症、委员会设计、蘑菇管理、死亡征途。43、具体情境决定一切”分享设计架构的理念让我觉得很滑稽，因为我认为压根就不存在设计理念““毕竟，没有理念本身也是一种理念”最重要的设计经验是具体情境决定一切，根据它设计尽量简单的解决方案。换句话说，架构决策只有在情境需要时，才能牺牲尽量简单的原则。脱离了具体的应用场景，孤立地比较技术的优劣是毫无意义的事。44、侏儒、精灵、巫师和国王架构师好比国王，应该熟悉各种人的性格特点，招聘不同性格的人加入自己的团队。安排任务时应该时刻考虑所有开发人员的性格特点。为不同性格的团队成员安排合适的任务，如果大家有机会磨合、相互适应，就能轻松化解决各种难题。45、向建筑师学习建筑师名言建筑师社会性的表演，是上演人类历史的剧院。要想成为伟大的建筑师，优雅丰富的心灵远比聪明才智重要。建筑师自诩上帝的助手，甚至觊觎上帝的宝座。（上帝：客户）天底下没有完美的建筑。建筑师首先应该是伟大的雕塑家，或者伟大的画家，否则他不过是个建筑工人。46、避免重复你的开发人员在重复无需思考的工作吗？代码里面反复出现某些相似的片段？某些代码是复制粘贴后稍加修改而成的，如果出现这些情况，说明团队工作效率不高。软件开发的真理：复制时魔鬼重复性的工作拖累开发的进度。消灭重复的内容是你的责任，为此，应该重新研究框架，创造更完善的抽象机制，请专门制作工具的程序员（toolsmith）帮你完成切面框架（aspect framework），使用代码生成器。要想消灭重复内容必须有人采取行动。47、欢迎来到现实世界工程师偏爱精确，整天和0和1打交道的工程师更是如此。现实世界不是二进制的。顾客有可能撤销确认过的订单，支票有可能跳票，信件可能丢失，付款时间可能延迟，许下承诺还可能失信。这些已经够糟了，可分布式系统又带来了新的不一致性。服务有可能失效，状态有可能在毫无征兆的情况下改变，事务处理可能得不到保证。分布式系统不但是松耦合、异步、并发的，而且不遵守传统的事物语义。48、仔细观察别试图控制一切妄想掌控一切的架构师只能设计出紧耦合的、脆弱的解决方案，这一套已经行不通了。我们必须启动必要的辅助机制。我们已经进入分布式、松耦合系统的时代。构建松耦合的系统多少有些麻烦，我们希望系统足够灵活，别因为一点点小的改动就支离破碎。随着系统的配置越来越灵活，当前的系统配置包含了更多的信息，为了便于理解，必须从中提取模型。比如，搞清楚哪个组件负责向逻辑信道发送消息，哪个组件负责接收消息，就应该把组件间的通信关系用图标模型记录下来。与模型驱动架构不同，你先构建出灵活的架构，然后从实际的系统状态中提取模型。49、架构师好比两面神罗马神话里面，两面神是司守门户和万物始末之神。他有两张面孔，凝视2个不同的方向。两面神兼顾前后，过去与未来。架构师在不同的对象之间架起桥梁，比如梦想和现实、过去的成功和未来的方向、业务目标与开发i限制。我们应该以两面神为榜样，工作上严格把关，综合考虑新情况与老经验，在成熟技术上不断创新，既满足当前的业务需求，又兼顾未来的额发展规划。50、架构师当聚焦于边界和接口“哪些应该在一起，哪些应该分开”51、助力开发团队架构师可以施加约束，也有机会成为推动者。要确保开发人员拥有他们所需的工具。要确保开发人员拥有所需的技能，确保他们能够获得必须的培训。同时，也要尽可能的参与到开发人员的选拔中。只要不违背软件设计的总体目标就让开发人员自己做决策。最后，保护开发人员，不要让他们卷入到不那么重要的工作中。52、记录决策理由在软件开发社区，对于文档尤其是关于软件自身设计的文档的价值，争论颇多。分歧一般集中于两处，一处是“详细的前期设计”的有效价值，另一处则是使设计文档化和不断变化的代码库保持同步的难易程度。记录软件架构决策理由的文档，长期有用，无需为之付出过多维护精力，具有很高的投资回报价值。根据项目的不同灵活选择合适的文档格式来记录架构决策的方方面面，格式可以是文本、维基、或博客形式的速记备忘录，也可以使用较正式的模板。比如这些文档：可以作为和开发人员沟通的工具，说明应遵循的重要架构原则当开发人员对架构背后的逻辑提出质疑时，使团队能够就事论事向经理和利益相关者说明这样构建软件的确切原因把项目移交给下任架构师好处是：它逼着你说出理由时，有助于确保基础是扎实稳固的、如果相关条件发生变化，需要对决策重新评估，它可以作为一个起点53、挑战假设，尤其是你自己的延迟判决法则：“臆断是事情搞砸的根源”软件架构师的最佳实践表明，应该记录下每个决策背后的理由，当这一决策包含权衡（性能vs.可维护性，成本vs.上市时间等）时尤须如此。有些小道消息：开源软件不可靠位图索引带来的麻烦比好处多....确保这些假设清楚明确，对后继者和未来的重新评估来说非常重要。更重要的是拿出证据。不要忽略相关这个词语。事实和假设是构建软件的两大支柱。务必确保软件的基石坚实可靠。54、分享知识经验从所有的失败的经验中，我们可以学到很多东西。在像软件开发这般年轻的行业中。为了持续发展传播经验和知识至关重要。每个团队在自己的小世界小角落里所学到的东西，可能会在全球产生影响力。55、模式病人们记录和发现模式，避免后来人重新发明车轮。对于软件架构师而言，设计模式是极有价值的可用工具之一。使用模式，能够创造更易沟通更易理解的通用解决方案。模式与良好设计息息相关，如果发现自己试图把最喜欢的模式硬套在不适用的问题空间上，那么你也许是”模式病“患者。不要让一展模式功底的欲望遮掩了务实真知。56、不要滥用架构隐喻架构师喜欢使用隐喻（metaphor）。对那些通常比较抽象、复杂和变化的移动的目标，隐喻提供了良好的具体媒介。找到实物作为正要构建的东西的隐喻，会更容易沟通和讨论架构全局。滥用架构隐喻经常会出现问题，让架构师不知所措，比如：业务领域的客户开始越来越喜欢系统隐喻，这时，系统还在构想中，在这种情况下所有各方共享的是最乐观的可能解读，但其中并没有包括任何必要的约束。开发团队认为隐喻比实际业务更重要。由于团队耽溺于隐喻，你不得不开始修正那些古怪的决策。所交付的系统包含了许多遗留名称，从早已老旧过时，有待重新鉴定隐喻，到多次重构和重复挖掘的概念。57、关注应用程序的支持和维护应用程序的支持和维护永远不是事后才考虑的事情。由于应用程序80%的声明周期都在维护上。开发人员和支持人员拥有的技能不同，就像开发/测试环境和生产环境有截然不同的目的一样。系统管理员会遇到的问题：*系统管理员不能重新提交请求消息来重现问题。*一旦投入使用，就没有调试器可以用了。....就会出现以下症状：*大多数问题都需要开发人员参与。*支持团队讨厌新的应用程序。....为了确保应用程序脱离开发人员之手后能成功运行，应该做到：*理解开发人员和支持人员确实具有不同的技能*在项目中尽早的引入支持负责人。...当系统管理员很开心的时候大家都会很开的。58、有舍才有得有时，接受某种约束或放弃某个特性，可带来更好的架构，这种架构在构建和运维上都会更加简单，而且成本更低，往往能产生富有创造性和创新性的结果。59、先考虑原则、公理和类比，再考虑个人意见和口味如果是单凭个人经验、意见和口味创建的架构是没有考虑原则、公理、和类比所带来的好处的。这样做，架构文档化会更容易，从描述架构所遵循的原则开始即可。原则清晰的架构能够把架构师解放出来，使其免于全面复审而忙得不可开交。原则和公理确保了架构的一致性。60、从“可行走骨架”开始开发应用为了实现、验证和不断发展应用架构，一个非常有用的策略，便是从Alistair Cockburn所谓的“可行走骨架”开始。“可行走骨架”是对系统的最简单实现（a minimal implementation),它贯穿头尾，将所有的主要构件组件连接起来。从可工作的最小系统开始训练全部的通信路径，可以带来“正朝着正确的方向前进”的信心。对于大型系统通常是由多名开发人员共同构成，对于大型系统而言更多的协调工作是必不可少的。从“可行走骨架“开始，保持系统一直运行可用，递增式地进行培育，使其逐步增长。61、数据是核心软件开发人员最初将软件理解为命令、函数和算法构成的系统。如果稍稍后退站远一点，计算机只不过是能访问与操作一堆数据的时髦工具。代码在计算机中运行时，底层数据的状态不断发生变化。举例而言，如果想了解Unix操作系统，通过源码逐行挖掘是不大可能奏效的，但是如果你读过一本unix内部数据结构的书，便可更好的了解unix底层是如何运行的。从概念上开看，数据比代码更加精炼，也更好理解。即使对于最复杂的系统，通过这种面向数据的视角，即通过底层信息的结构整体开看待系统，也可以将之缩减为细节的有形集合。然后降低其复杂性。数据在大多数问题中处于核心地位，业务领域问题由数据蔓延到代码中。诚然，软件架构中的许多问题确实和数据相关。从设计角度来看，大多数系统的关键问题，就是要在正确的时间从系统获取正确的数据。62、确保简单的问题有简单的解软件架构师解决了许多非常困难的问题，但也会解决一些相对容易的问题，对于简单的问题，不要使用复杂的解决方案。为复杂问题付出的直接成本可能看上去很小，但是其潜在成本要大得多。为问题的解决方案付出的代价不仅仅只是在实现和维护上。架构师会从主观的判断或潜在不确定性需求出发，产生调整解决方案的强烈冲动。但记住一点：试图猜测未来的需求时，错的概率是50%，错的非常离谱的概率是49%。63、架构师首先是开发人员不管解决方案多么优秀，决定实现能否成功的最重要因素之一是让开发人员愿意接下任务。虽然不是工作的一部分，架构师还是会经常去处理一些比较复杂的任务。这样做的目的有两个：第一，这是一种乐趣，而且还能帮我们做到宝刀不老；第二，这有助于向开发人员表明，我不是碰到麻烦时会干吹烟卷却束手无策的架构师。64、根据投资回报率进行决策（ROI）我们对项目所做的每一个决策——无论是技术、过程，还是与人相关——都可以看做一种投资形式。回报率（rate of return），也成投资回报率（Return On Investment,ROI)，是衡量投资是否成功的标准之一。将架构决策视为投资，并将相关的回报率也一并考虑在内。在判断每个决策选项是否务实或恰当时，这种方法很有用。65、一切软件系统都是遗留系统即使系统十分前沿，采用了最新的技术开发而成，但对接手它的下一个人而言，它也会是遗留系统（legacy）。必须面对这种情况！在今天，软件很快便会过时，这已经成为软件的天然属性。如果软件能够存活下来哪怕只有数月的时间，都必须承认一点：负责维护工作的开发人员肯定要对软件进行缺陷修复，这是不可避免的。这引出如下几个问题。*清晰性：各个组件和类的角色一定要清楚*可测行：系统易于验证吗？*正确性：结果和设计或期望的一致吗？*跟踪性：可容易修复紧急缺陷66、起码要有2个可选的解决方案对于某一个问题，如果只考虑了一个解决方案，那你就有麻烦了，在给定的约束条件下，寻找问题的最佳方案，期望第一个解决方案即满足全部的需求和约束，几乎是不可能的。这种问题即使有——也绝少是真地由于缺乏可选方案而造成的，它更可能是架构师缺乏特定问题域的经验所致。67、理解变化的影响好的架构师能够将复杂性降到最低程度，他在解决方案中给出的抽象，应该能够为更高的层次提供坚实基础，同时，还应该能足够务实地应付未来的变化。优秀的架构师能够深刻理解变化带来的影响，这种影响不仅限于彼此隔离的软件模块之间，而且包括人与人之间，以及系统与系统之间。变化有多种不同的表现形式：*功能需求的变化*可扩展性需求的变化*系统接口被修改。。。。幸运的是许多工具和技术可以用以减轻变化的影响：*进行小规模的增量渐变*构建可重复运行的测试用例*跟踪好依赖关系*降低复杂性*自动化重复任务68、你不能不了解硬件对于许多软件架构师，硬件容量规划问题是一个超出其舒适区的主题，但它的确是架构师工作的重要组成部分。如果没有硬件方面的专业知识，预估待开发系统的硬件配置是非常容易出错的。比起采购超出实际所需的硬件，为容量规划留出预算是更为经济的。69、现在走捷径，将来付利息长远看来，系统维护将比项目初期的开发消耗更多的资源。测试：使用测试先行的设计，进行单元测试碰到架构问题或设计缺陷，作为架构师，一定要坚持成本还很低廉时就动手。搁置越久，为之付出的利息也就越高。70、不要追求完美，足够好就行软件设计师，尤其是架构师，在评估针对某个问题的解决方案时，会倾向于考虑它是否优雅完美。有些瑕疵只须经由一些调整或迭代重构便可消除。建议：不要屈服于企图使设计或实现达到完美的诱惑！把目的设定在“足够好”就行，当已经达成目标时就停下来。71、小心“好主意”“好主意”会杀死项目。有时候杀伤力会很快见效，但更常见的症状是：因屡屡错过的里程碑和不断攀升的缺陷数量，项目苟延残喘，最终不治身亡。“好主意”：那种诱人2的、不用想都知道的、外表无辜、以为不可能会产生伤害的那种“好”注意。“好主意”真正的邪恶之处在于它的“好”。如果出现下列关键词，要小心了：*如果....会更酷。*“嘿，他们刚刚发布了YYY框架的XXX版本。我们应该马上升级”。72、内容为王我见过无数这样的设计，它们大都永无止境地强调需求、设计、开发、安全及可维护性，但从未关注系统的真正要点——数据。73、对商业方，架构师要避免愤世嫉俗雇主希望偶们能够解决问题，倾听和了解雇主的业务，是我们必须掌握的最为关键的技能。成为优秀架构师的秘诀之中有一个关键要素，那便是:要对工作满怀激情，但不要是那种带着愤怒和火气的“激情”。74、拉伸关键维度，发现设计中的不足应用程序的设计轮廓，最初是基于特定的业务需求、所选择的技术或现有的技术、性能要求、预期的数据量，以及构建、部署和运营上可用的财务资源。无论采用什么样的解决方案，都要求能满足或超越当前环境下的要求，成功运行起来，否则这就不称其为解决方案了。拉伸解决方案的关键维度，看看哪些方面会遭到破坏。75、架构师要以自己的编程能力为依托在架构上，架构师都期望能够创建出精巧的设计和完美的抽象，来优雅的解决手头的问题。如果能再项目中多安插些技术那就更让人有成就感了。但是最终要实现设计的不是架构师。如果开发人员需要去实现那些架构上的“杂技”，那将会对整个项目造成巨大影响为项目设计架构时，对实现的每个设计元素所需要的工作量，要做到心中有数；如果以前曾开发过其中某种设计元素，那么估算所需的工作量将会容易得多。不要在设计里面使用自己没有亲自实现过的模式，不要使用自己没有用之写过代码的框架，不要使用自己没有亲自配置过的服务器。76、命名要恰如其分如果都不知道一个东西应该叫什么，那你肯定不知道它究竟是什么。如果你不知道它究竟是什么，那么你肯定不能坐下来为它编写代码。77、稳定的问题才能产生高质量的解决方案最好的架构师不是要去解决难题，而是围绕难题开展工作。架构师要能够将四处弥漫的软件问题圈起来，并画出其中的各种边界，确保对问题由稳定的、完整的认识。这些问题应该具有以下特性：*内聚性：问题块在概念上市统一的，其中所有的任务、数据和特征都是相关的。*能够很好地和其他块分隔开：这些块在概念上进行了规范化处理；他们很少重叠或者根本不重叠。78、天道酬勤架构师常常被描述为一种注重创造力与问题解决能力的职业。除了创造力外架构师还应当具备另一项同样重要的特质——勤奋，勤奋指很多方面，但归根结底是指具备坚强的毅力，并且对系统的每项任务和每个架构的目标都能投入足够精力。勤奋经常和平凡携手同行。勤奋还意味着要求架构师必须真正做好那些看似简单的任务，坚守承诺。79、对决策负责由于软件架构师比组织中的其他人更有影响力，所以他们必须对自己做出的决策负责。研究表明有超过三分之二的软件项目要么彻底失败了，要么未能成功交付（项目延期、预算超支、客户不满意）。究其根本原因，有许多事由于架构师做出了不当的决策，或者无法最终执行正确的架构决策。如何做出有效的架构决策：首先,对决策的过程有充分认识第二，定期对架构决策进行复审第三，要贯彻架构决策最后，可以将一些决策委托给响应问题域的专家，不必出自其自身。80、弃聪明，求质朴智力超群、足智多谋对任何人来说都是值得称道的品质。对架构师来说，这些素质尤其被看重。然而，聪明也包含某些额外的隐含意义。它也暗指能快速想出脱身之计的能力，但这种本领最终要依靠一些小伎俩，骗局或掉包计。聪明的设计僵硬难改，其细节会对全局产生太多牵扯，往往会一触即毁。81、精心选择有效的技术，绝不轻易放弃作为软件设计开发的老手，每个架构师通常都有一些让自己屡屡取胜的武器用来武装自己。这些技术由于种种原因深受架构师青睐，排在其首选解决方案的前几位。这并不是说某种技术一旦入围就可以永久罔替。选择新技术虽然有风险，但其价值能为你带来质的飞跃。考虑技术未来的前景。软件架构师工作很大一部分，是要选择用以攻克难题的合适技术。82、客户的客户才是你的客户在软件会议需求会议上，要这样想象：你的客户并不是你的客户。实际上真的不难做到，因为，事实便是如此。如果你的客户的客户赢了，那么你也赢了。如果你在编写一个电子商务应用程序，那么应该考虑的应当是那些会在那个网站上购物的人的需求。如果你的客户有意无意的忽视他们的客户所看重的重要事项——那么请放弃这个项目。需求收集会议不是项目实现讨论会议。83、事物发展总会出人意料事物的发展总会出人意料。在设计时，人们很容易陷入误区，投入太多的时间在设计上。设计中的这些微小变化累积起来，很快就需要对设计进行一次较大的变更。设计是一个不断发现的过程。84、选择彼此间可协调工作的框架软件框架是系统的基础，在选择时，不仅要考虑每个框架自身的质量和特性，也要关注共同构成系统的各个框架之间是否能和谐相处。如果框架间有重叠，则要确保了解候选框架在逻辑域或关注层面上的重叠程度。为了尽量减少框架间互有重叠的概率，要根据系统需求的应用场合，选择精专强大的框架。系统应该由多个相互独立的框架构成，其中每个框架都精专于各自的领域，但同时又非常简洁、包容、灵活。85、着重强调项目的商业价值对于非软件业从业人员，软件架构显得虚无缥缈，架构项目在争取资金时会遭遇到困难。大众心理学表明，大部分人会相信亲眼所见的东西。而拥有预算决定权的人，几乎都是受商业价值驱使的。下列五部，会成功将架构提案打造成经典的商业项目：1、形成价值描述（提高 生产力，改进效率的能力）2、建立量化度量标准3、回过头来关联传统商业的衡量方式4、知道该在哪里停止5、寻找恰当的时机86、不仅仅只控制代码，也要控制数据源代码的控制和持续集成，是管理应用程序构建过程和部署过程的优秀工具。数据方案和数据内容常常会根据源代码的变化而变化，他们也是这一过程的重要组成部分，因此也要对之进行类似的控制。数据库的变化不应该影响构建活动的连续性。要把数据库也作为一个构建单元包含在内，做到一次性构建整个应用程序。数据迁移不应该作为一种补救措施。87、偿还技术债务对任何已投入实用的项目（也就是说，有客户在实用产品），无论是要修复缺陷，还是要添加新功能，总有必须修改产品的时候。在那点上，会面临2个可能选择：花合适时间“一次做对”，或者取巧走“捷径”，争取尽快推出修改过的产品。作为架构师必须决定怎么做才有意义。88、不要急于求解架构师多半是开发人员出身。开发人员的主要职责是解决编程问题。相比架构问题编程问题的范围更狭窄。很多编程问题是很小但比较棘手的算法问题。架构师和开发人员因此学会了迅速进入问题解决模式，但有时候没有解决方案才是最好的而解决方案。许多问题根本不需要解决，看似问题是因为我们只关注表面症状。学会审视问题本身。看看能否改变问题。我们必须戒除“问题解决迷恋症”。89、打造上手的系统我们十工具的制造者。我们制造的系统，一定要能够帮助人们——通常是其他人——做事，否则就是去了存在的意义，我们也将无法从中获取报酬。用户体验应该是“上手的"。90、找到并留住富有激情的问题解决者组建一支汇聚优秀开发人员的团队，是确保软件项目成功非常重要的事情之一。一旦建成便竭力维护。提放批评过度。批评过度，可能会扼杀开发人员的创造力，降低其生产力。更糟糕的是，可能会在团队内部造成纷争。以正确的方式经营开发团队，其重要性不言而喻。91、软件并非真实存在软件工程经常被拿去和完善的传统学科——如土木工程——进行对比。这些类比有个问题，和这些传统实践制造的有形产品不同，软件并非真实的存在。业务和软件都是活生生、会变化的实体。业务需求可能会因新近收购的业务伙伴和营销战略而迅速变化。业务需求很可能会发生变化，因为我们构建的产品是柔韧的。记住，需求文档不是蓝图，软件并非真实存在。我们创造的虚拟物比实体物更易于改变。92、学习新语言架构师必须让别人能理解你。业务人员专业用语和程序员专业用语是有差别的。架构师需要掌握各个沟通团队的语言。93、没有永不过时的解决方案今天的解决方案会成为明天的问题。今天做出的选择，在未来很大程度上是错误的。“分析瘫痪”是今天架构师们碰到的问题之一，此问题最大的归因，是试图去猜测对未来而言最好的技术。94、用户接受度问题人们并不总是满心欢喜地接受新系统或系统的重大升级。这种情势，可能会对项目的成功构成威胁。架构师的目标，是要去了解和衡量用户的接受度问题带来的威胁，并朝着能减轻这些威胁的方向开展工作。“项目拥戴者”可以帮助消除用户接受度问题。这个职位的最佳人选，是能代表用户或利益相关方的人。95、清汤的重要提示清汤是一种非常清澈的肉汤，上品清汤非常清澈，需要不断重复的精炼浓缩才能烹出。设计架构也应当不断精炼浓缩。软件中许多漏洞的需求和缺陷，可最终追溯到含糊笼统的语言描述上。拒绝模凌两可的废话。概念需要在加上“总是、永远、不管任何情况下”仍然成立。96、对最终用户而言，界面就是系统糟糕的用户界面埋没了太多的好产品，最终用户通过界面访问系统。架构师应该确保，随着架构变化而变的用户界面也要能够反应用户的期望。不仅要让最常用的交互易用，而且要使最终用户能够从中获得回报。97、优秀的软件不是构建出来的，而是培育出来的在一开始就要设计庞大的系统几乎毫无好处可言。设计尽可能小的系统，帮助成功交付，并推动它向宏伟的远景目标不断演化。粗略的从后面的十几个里面提取出以下几个方面：数据：程序的核心就是数据，数据的结构表现出数据的形态，数据可能会随着架构更新，数据库也要更新。文档：文档是为了避免反复思考而存在的，类似于代码注释，文档是对工程的注释。尤其是对架构师的每一个有可能产生分歧的决策，必须用文档标明决策原因。推迟决定（也有其他翻译）：是软件开发模型的策略，这样有助于收集更多有关决定的信息。团队：团队需要的不是单一的一类人，但需要的一起能合理分配工作并完成工作的一类人。找到好的团队成员一定尽心维护。用户：客户至上，客户体验是架构师最好的简历，标志着软件的成功与否。沟通：和业务部门沟通，需要学习业务部门的语言，其中涉及到一些专业词汇，避免沟通障碍。和客户沟通明白需求，和程序员沟通....选择技术：如何选择使用的技术，要考虑的事项（如：架构师本人的技术，对于软件的性能，不同架构一起融合等）性能：相对于功能而言，性能经常被忽略。——————作者：H100来源：CSDN原文：https://blog.csdn.net/u014449046/article/details/49390571版权声明：本文为博主原创文章，转载请附上博文链接！
安全可靠技术和产业联盟-会员单位介绍（2018）
安可联盟，全称是“安全可靠技术和产业联盟”，它的前身是“信息技术应用创新工作委员会”。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
据预测，未来 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 的解释也着重于一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。因此，开发、测试和 IT 运维团队之间的沟通对于 DevOps 的成功至关重要。六、目标明确虽然不同团队之间的沟通至关重要，但明确定义每个人都在努力实现的目标同样重要。归根结底，所有团队都有同一个目标：让组织更有效率。但是，他们为实现这一目标而遵循的个人实践可能会有所不同。团队成员应了解实现目标所需满足的精确要求，而不是做出假设或任其发展。七、使用正确的工具和平台DevOps 不仅仅是一种文化转变——它需要强大的工具才能实现。在实践过程中，如果你发现往往需要花费大量时间来解决出现的问题，那么很可能是因为你没有选择正确的 DevOps 工具。幸运的是，目前的市场上有大量且广泛的 DevOps 工具可以选择，以适应当前现有的所有的数字化基础设施。尽管工具是 DevOps 的重要组成部分，但是要记住，真正使改变发生的是实践。在众多 DevOps 工具中，近两年来被业内广泛关注的飞算SoFlu因其对软件开发流程的变革而被大量企业应用于DevOps落地，飞算SoFlu是一款管理加开发工具，通过可视化编程的方式满足开发需求。使用平台的一个ID相当于一个10人科技团队，从而使用户有更多精力可以更多关注自身业务。飞算SoFlu中包含的三大核心技术，全都是 DevOps 实践中所要关注的重点：1）可视化开发改变传统开发方法，业务逻辑可视化展示，降低开发门槛，无需编写代码，在设计业务逻辑时就形成微服务应用。2）平台组件可视化平台组件是一类通用的技术功能模块，平台支持循环条件判断，函数调用，通过拖拽方式以及参数配置实现等同于编写复杂代码的业务逻辑，有别于通过组件排列组合。3）管理方式主要通过管理平台来管理需求、研发、测试、部署、上线、运维等整个软件生命周期，经验沉淀、知识积累，将管理制度真正的落地。截至目前，飞算SoFlu已为包括医疗、金融、制造、零售等在内的八大行业的上百家机构提供了技术服务，助力其落地DevOps，提升研发效率。一个典型的案例是，飞算SoFlu在某大型国有银行的应用。该银行原本需要3天才能开发完成的接口，使用飞算SoFlu，仅用了5个小时。其IT负责人表示，使用飞算SoFlu后，银行软件中心的整体研发效率获得了大幅提升。飞算SoFlu的DevOps功能正是在不断的实践中完善升级，从实际业务出发，真正让企业实现降本增效。
微服务变得越来越理所当然，似乎我们一直生活在微服务的世界中。很多时候，我们常常讨论微服务采用与否、如何选型等问题。但本文作者 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 大型（64vCPU、512GB RAM）服务器。你曾经部署过单体应用吗？当然，我们可以将其复杂化，但在常规情况下，如果将应用程序部署到云上，单体应用就是你所需要的形式。让我们以一个简单的在线商店应用程序为例：应用程序的一个负载均衡器运行应用程序的一个计算实例应用程序的一个（关系型）数据库用于日志聚合的 Kibana 如果你用的是微服务：一个 Kubernetes 集群一个负载均衡器运行应用程序和托管 K8S 集群的多个计算实例一个或多个（关系型）数据库，取决于你是否每个服务用一个数据库一个用于服务间通信的消息系统，例如 Kafka用于持续集成（持续部署）的 Jenkins用于日志聚合的 Kibana用于监控的 Prometheus用于分布式跟踪的 Jaeger/Zipkin 而且这只是一个高层级的概览。微服务确实可以产生价值，但问题是：代价是什么？尽管这些承诺听起来很好，但你的架构中有更多活动的部件，这自然会导致更多的失败。如果你的消息系统挂了怎么办？如果你的 K8S 集群出现问题怎么办？如果 Jaeger 宕机，而你无法跟踪错误怎么办？如果指标没有进入 Prometheus 怎么办？显然，你将花费更多时间（和金钱）来构建和运转这个复杂的系统。更快的部署?我将讲讲优势列表中的第一点：更快的部署。当你想到 Netflix、Facebook、Twitter，并且观看他们的会议演讲，他们描述他们正在运行的微服务数量，以及他们如何向 Git 提交内容，并在数小时内将其投入生产。这是不是好得难以置信？在我看来，这绝对是可以实现的，但我承认我从未参与过这样的微服务项目。我并不是说这是不可能的，只是从稳定性、基础设施和团队文化角度来看，这真的很难实现。让我分享一下我是如何从我的经历中得出这个结论的。在对一个全新的项目进行编码之前，你通常会先研究如何将产品转变成技术方案。你会设计系统，设计微服务，会有多少个微服务，每个微服务的职责等等。有一个真正的教学项目，我们在这个项目中练手，我们最终做了 80+微服务，用了多长时间呢，4 个月？这 80+微服务的现实意义是，与其将这 80+微服务一起组合成一个单体应用并部署这个单体应用，部署单个微服务绝对会更快，但是.......这 80+微服务太小了，以至于一个开发单元——敏捷领域的叙事——永远不可能只涉及一个服务。系统从根本上被破坏了，更快的部署的承诺立即消失了。我们不再拥有更快的部署，而是相反，更慢的部署。而且慢得多。另外，我会反复思考这个问题。部署过程中活动的部件越多，意味着潜在故障越多。很多时候，基础实施不够稳定，部署会随机失败，因为：在下载/上传软件包时，Artifactory/Nexus/Docker 仓库短时间内不可用；Jenkins 构建器随机卡住。这只是其中的一部分。产品必须分解为微服务。每个服务都必须对其自己的事情负责。例如，Netflix 中的一个推荐服务应该负责向用户提供推荐。不是谁都是 Netflix，也不是所有东西都容易分解成合适的大小和职责。这是领域驱动设计（Domain Driven Design，DDD）和有界上下文可以提供帮助的地方，但这实践起来并不容易，有时甚至没有足够的时间/开发性来试验这些方法。配套文化无论如何，在我看来，微服务的第二个困难是组织/项目文化。如果产品（部门）根本不关心底层系统架构会怎么样？我是说，他们会关心吗？举个例子：如果你有一个拥有大量微服务的复杂架构会怎么样。产品负责人进来对团队说，让我们开发整个功能。在团队分析完功能请求后，发现它涉及 10-15 个微服务，因为它与许多其它的已有功能有关联。那你会怎么办？你试图将它分解成更小的部分，但是这么做到底对不对，这里存在着疑问，因为每个小部分的功能没有意义，而且逐个服务发布它会增加大量开销。你当然不能对产品负责人说，仅仅因为我们用的是微服务，所以我们需要 3-4 倍时间，对吧？这个对话会是什么样子？产品经理：嗨，伙计们，我想到了一个非常棒的功能。我们的竞争对手也准备做这个功能，所以我们要快点实现它。2 周做完，可以吗？团队：好吧，初步看来，我们可以实现这个功能。而且这个功能看起来也是一个好主意，可以带来更多的客户。我们会重新组织，好好谈谈。团队：好吧，2 周有一点儿问题。因为我们用微服务是为了更快，我们需要更多时间来实现这个功能，由于我们需要涉及 15 个服务，因此我们需要 6 周的时间来完成初步实现。产品经理：初步实现？团队：是的。这 15 个服务之间的通信非常重要，因此初步实现不会包括异常处理、弹性通信模式、调试跟踪等其它东西。如果做这些的话，我们还额外需要 4 周时间。产品经理跳窗了更好的故障隔离这一点自然是正确的。如果一个服务挂了，只有那个服务会受影响，对吧？虽然确实如此，但这并不是绝对的。让我给你展示 Netflix 的一个虚拟架构图——我对其进行了简化：假设用户想要看推荐。请求转到推荐服务，它查询用户数据来了解用户详情，并将推荐存储在其数据库中（不在图片上），而且由于这是用户相关的数据，所以它们可能需要将其加密。现在，如果数据加密服务挂了会发生什么？我们还能做推荐吗？肯定不能，因为我们不能加密用户数据，所以我们自然会说，嘿，伙计，我们现在不能给你推荐，请 5 分钟后再试。这个故障影响到系统中的推荐服务，系统会以无法立即提供推荐的事实来优雅地做出回应。但是你知道要优雅地处理这类情况需要做多少工作吗？非常多。让我们再举一个例子。用户尝试使用登录服务来登入系统。数据加密服务仍在故障，登录服务调用分析服务来获取在一个时间区间内有多少用户正在尝试登入的指标，以及其它一些虚构的指标。不过，分析服务也在与数据加密服务通信，因为这些数据也需要加密。现在，编写分析服务的团队正忙着，没有时间来实现适当的异常处理，因此数据加密服务的问题会转而影响到登录服务。显然，登录服务是在几个月前完成的，这个服务没有准备好处理来自分析服务的底层错误，因此即使不关键的分析服务失败也会导致用户登录被拒绝。而且我知道你是怎么想的。是的，实现登录服务的团队不负责为处理这种情况做准备，但是如果他们认为分析服务会优雅地处理这个异常呢？这已经写在分析服务的 API 合约中，但它没有那样生效。那么，当你在一个单体应用程序中，会发生什么呢？一个服务崩溃在这个上下文中并没有真正的意义，但假定由于某种原因，连接到数据加密的数据库表不可访问了。在这种情况下，异常处理非常简单，因为你只需要准备一个 exception 就可以了。但是在过分赞扬单体应用前，需要说的是，单体应用也有缺点，如果单体应用挂了，什么东西都不可用了。因此，这是一个平衡问题，需要问问你自己。是实现一个 try-catch 代码块更容易，还是处理一个同步 HTTP 调用异常或异步消息异常更容易？我记得，对于 80+微服务，标准化异常处理是非常了不起的事情，它需要一个团队花费数月来完成。这甚至不意味着在每个地方都引入异常处理，而只是将现有的异常用我们使用的一个自定义库重写，这样我们就可以减少未来异常处理场景所需的繁琐工作。关于作者Arnold Galovics 六年级就开始学习 Flash 编程，之后开始接触 HTML、CSS、JavaScript，在高中时期学了几年 Pascal，然后在大学开始学习 C、C++和 Java。Java 是其职业垫脚石，他为 Java 投入了大量时间。2012 年开始作为全职软件开发者，参与金融行业、OAuth2、与 OpenID 兼容的身份验证平台、物联网等应用程序的开发，主要专长是 Java 及相关框架，熟悉 Spring、JUnit、TestNG、Mockito、JPA、Hibernate，以及 Kubernetes、Kibana、Ansible、Jaeger、Zipkin、Kafka、MQTT 等。只要是跟 Java 相关的开发技术、基础设施、云、架构都比较熟悉。在过去几年中，他过渡到了团队管理的位置，团队规模从 5 人增长到 35 人，试图使用 Scrum 和 Kanban 来实践敏捷方法，希望在团队成员个人创造力与公司目标之间取得平衡。原文链接：https://arnoldgalovics.com/microservices-in-production/