首页 文章 精选 留言 我的

精选列表

搜索[云帮]，共10004篇文章
优秀的个人博客,低调大师

强化物联网 区块链帮大忙

看好物联网未来市场发展潜力，信息电子厂商皆积极展开智能工厂、车联网等，物联网垂直领域应用相关开发、布局与试验。然而，在此同时亦出现对于物联网发展的各种条件，包含安全风险、维运成本过高、获利模式等是否已完备的质疑。 安全是常被提及的物联网潜在风险。联网的复杂性使安全防护更加困难，当连上物联网的各式装置愈来愈多时，网络即可能出现被攻击的破口，一旦控制系统遭到攻击入侵，轻则数据外漏，重则危及人身安全。 IT业者惠普检视目前主要的物联网系统，发现有80％进行数据传输时未加密，60％进行软件更新时未加密等问题，显示出联网装置安全防护常被忽略，物联网潜在安全问题相当严重。 维运成本过高则是物联网发展的根本问题。维运成本高是商业模式无法获利的原因之一，存在因果关系。此乃由于目前物联网应用思维仍停留在传统的模式与架构，需要第三方中介者，且使用云端集中式管理，设备投资与维护费用相当高，导致维运成本居高不下。 长期而言，若如同预测十年后，联网装置达到300亿至500亿个的规模，届时必须在物联网平台上，精准监管亿级数量的装置，并同步收集与处理装置产生的庞大数据量，就是极大的挑战。 此外，软件为物联网应用之核心，必须持续投入研发与维护，不仅造成业者营运沉重负担，亦压缩可能的获利空间。联网对象使用周期长，例如生产设备、汽车10年以上、住宅建筑40年以上、公共设施50年以上，但软件技术发展快速，几年就需进行更新，因此须长时间投入软件维护。 智能手机等消费性产品虽然亦有软件更新问题，但用户大约二、三年就换购新机，创造的新营收可支撑相关研发费用，并维持获利。目前物联网的应用主要集中在喷射引擎、大型建设机具、智慧电网、远距医疗等高附加价值的领域，其他如智能家庭等领域进展则相对缓慢。 在此状况下，因金融科技风潮而受到关注的区块链（blockchain）技术，由于具备去中间化、不可逆的安全性、快速交易决算、自动执行合约等特性，可解决物联网安全、维运成本高的痛点，加上在比特币等虚拟货币的自动交易上，已经验证可行，而被视为加速物联网应用发展的有力技术选项。因此除国际大厂展开相关应用实证测试，亦吸引许多新创公司投入研发。 IBM与Samsung合作执行ADEPT计划，以共同开发的洗衣机W9000 ，进行自动叫修、洗衣剂等耗材管理、电力管理等实验，这些运作都在区块链上完成，只要事先以智能合约的计算机协议做好约定，在确认合约有效后，就会自动进行维修、送货、付款或设备间的协作等动作。 德国新创Slock．it运用区块链技术，开发称为以太坊计算机的小型消费电子装置，以智能锁结合物联网，让持有者欲租赁、出售或分享资产时，只需事先设定智能合约、保证金与收费金额，使用者支付相关款项后，即可开锁使用，在无中介者、无人管理，自动完成交易，降低营运成本。 物联网的技术涵盖面广，应用多元，目前仍处于从摸索到测试的发展初期阶段。各种有助落实相关应用的技术将陆续被提出，但是除技术面验证需要时间，形成生态系更非一朝一夕可达成的事，因此短期内恐难归于一宗，出现主流。物联网应用上结合区块链技术想法的提出已有一段时间，虽然目前应用仍以试验或小规模营运为主，但至少提供相关业者一个具可行性发展方向。而由于物联网各环节技术关联性高，区块链亦不可能自成一格独立发展，实际应用需考虑因素仍多，应仍在萌芽。 本文转自d1net（转载）
2017-07-02
优秀的个人博客,低调大师

Linus 亲手帮英特尔优化 LAM 代码

去年年底英特尔将 LAM（Linear Address Masking ：线性地址掩码） 功能提交到 Linux 6.2 的合并窗口，但该功能受到 Linus 的批评并拒绝合并。在经历了一段时间的代码改进后，Linus 终于同意将 LAM 代码合并到 Linux 6.4 窗口。 但 Linus 似乎仍对英特尔工程师提交的代码不太满意，在合并了 LAM 代码后，先是写了一个使 access_ok() 独立于 LAM 的新补丁，而后又亲手写了多个补丁对 LAM 代码进行了优化。 在最新提交的 LAM 优化补丁中，Linus 解释了自己的动机： 我对此版本中的 LAM（“线性地址掩码”）的 “access_ok()” 的完成方式感到很不爽，而且它实际上也有一些小 Bug ，所以我动手清理了代码。 改动主要集中在以下几方面： 使用 __user 指针的符号位而不是屏蔽地址，并根据 TASK_SIZE 范围检查它。 get/put_user() 端做了这部分，但是 'access_ok()' 做了天真的“掩码和范围检查”，它不仅生成多余的代码，还意味着 __access_ok 本身的任务做得不好， copy_from_user_nmi() 没有得到正确的检查。 将所有 64 位代码仅移动到 64 位版本的头文件中，这样就不会污染共享的 x86 代码，也不会误导用户 LAM 可以在 32 位环境中工作。 修复地址掩码中的 Bug（这不重要，只是完全删除了错误的代码）。 几个简单的清理，并添加了关于 access_ok() 规则的注释。 Linus 重新编写了约一百行代码来清理 LAM ，这意味着如果测试没问题， 就可以在 Linux 6.4 中顺利启用LAM 功能。不过这次 Linus 竟然亲自动手为英特尔工程师修改“有瑕疵的代码”，这种情况相当少见。
2023-05-09
优秀的个人博客,低调大师

API网关帮后端服务做连接管理

当一个互联网产品业务量越来越大，她接入的客户端也会越来越多，不管客户端使用的是长连接还是短连接，对用户的连接管理必将成为一件耗资源且复杂的事情。特别对于使用HTTP短连接进行数据交互的业务，在HTTP连接维护上面，需要花费比较大的开销。 让我们来看看使用HTTP短连接来完成一次数据交互的全过程。 众所周知，HTTP是基于TCP的协议，而使用TCP进行通信前，首先需要通信双方建立TCP连接。我们来看看客户端是如何和服务器端建立连接的： 请求新的TCP连接时，客户端需要向服务器发送一个小的TCP报文(通常是40-60字节)， 这个报文设置了一个特殊的SYN标记。说明这是一个连接请求； 如果服务器接受了连接，就会对一些连接参数进行计算，并向客户端回送一个TCP报文，这个报文的SYN和ACK标记都被置位。ACK标记被置位是告诉客户端，服务器端已经
2016-11-11
优秀的个人博客,低调大师

EVERTEC是如何利用大型机帮客户省钱？

EVERTEC，一家总部位于波多黎各首府圣胡安的公司，主要提供商户收单、付款处理、业务流程管理等服务，目前业务已经涵盖加勒比和拉丁美洲的19个国家。 EVERTEC的主要客户以企业、政府机构、金融机构和商人为主，每年处理的业务数超过21亿笔。该公司成立于2004年，并于2013年成为波多黎各首家在纽约证券交易所上市的技术公司。 以政府机构为例，出于安全性方面的考虑，之前是由EVERTEC帮助其托管了两套计算机系统，其中一套是以虚拟化的方式运行在IBM zEnterprise主机的z/OS平台上，另一套运行在IBM的z/VSE平台上。EVERTEC最终帮助其制定的更有成本效益的方案是将两套主机系 统整合在统一的z/OS环境中。 “速度、安全性和可靠性是我们最关注的，而这些IBM平台都能满足，”EVERTEC主机系统经理Jose Correa表示。 使用一套基于z/OS的主机意味着应用能够更好地服务于机构。毕竟使用单一平台，用户在软件授权、应用开发方面的成本更低。同时，业务运行在z/OS上代表着更简化的管理、更高的服务质量和更强的灾难恢复能力。 在EVERTEC托管整个基础设施前，过去几十年运行在z/VSE环境中的应用，大部分都使用COBOL和汇编工具编写，而这些必须要迁移到z/OS平台。所以在信息的建设和恢复中，EVERTEC其实面临着不少技术性的难题。 在该项目中，EVERTEC与IBM紧密合作，克服了迁移过程中意想不到的难题（其实在所有项目中，EVERTEC均与IBM保持着良好的合作关系）。对于政府客户来说，这是个两全其美的事，使用单一平台光许可费用每月就可以节约34000美金。除此之外，业务运行在一个统一的平台上还能减少架构复杂度、降低运营管理成本、减少业务恢复时间。 将业务迁移至z/OS单一平台上意味着有更多的开发者能满足企业的需求，意味着应用更容易实现，意味着商业更灵活更可靠。迁移带给终端用户的改变显而易见，业务响应速度更及时，生产效率更高。 EVERTEC在z/OS方面的经验和专业知识让其在为业界提供高性能的主机系统和领先的基础 架构平台方面竞争力大幅提升。“我们有一套智能的IBM主机基础架构系统，这能让我们更快的为客户部署更具成本效益的解决方案”，EVERTEC执行副总 裁和CIO在接受采访时表示。 收藏 分享 转发 点评： 可能更多人关注到了大型机的可靠性、安全性和性能，但其实大型机还有很重要的一个特性， 那就是其强大的整合能力。文中已经多次提到了整合对于企业意味着什么，更低的采购费用、更少的软件许可费用、更少的运营管理费用，而这些带来的直接收益就 是用户可以把更多的精力投入到自有业务的创新中。 当然，除此之外，安全性、性能、可靠性这些老生常谈的优势还是值得关注，特别是当IBM LinuxONE推出后，用户以较低的成本就能享受其带来的性能、安全性、可靠性及整合能力方面的优势，这在以前都是不可想象的。 原文发布时间为：2016-05-31 本文作者：李祥敬 本文来自云栖社区合作伙伴至顶网，了解相关信息可以关注至顶网。
2017-08-31
优秀的个人博客,低调大师

Istio来帮您！

如果你正在使用容器，特别是Kubernetes，那么你应该也听说过Istio。对于初学者来说，Istio是Kubernetes的服务网格（service mesh）。所谓服务网格，它是一个网络层，并且可以动态管理服务流量，然后以安全的方式进行管理。 如何充分使用Istio，这不是一篇博客文章能阐述清楚的。因此，在本文中我将介绍一些它的特性，更重要的是，你可以通过这篇文章，了解到一些方法来自动化解决某些实际问题。 Istio可以让你使用一组自定义Kubernetes资源来管理网络流量，并且可以帮助你保护和加密服务之间以及集群内外的网络流量。它全面集成了Kubernetes API，这意味着可以使用与其他Kubernetes配置完全相同的方式来定义和管理Istio设置。 权衡利弊,再做选择 如果要开始使用Istio，首先应该问自己为什么。Istio提供了一些非常有价值的功能，如金丝雀发布等，但是如果不增加一些复杂性，就无法使用它们。你还需要投入一定的时间来学习它。也就是说，如果你的情况合适使用它，你可以（并且应该）在自己的集群中谨慎且逐步地采用Istio的功能。 如果你要从头开始构建新环境，并且经过利弊权衡决定继续使用Istio，那么一定要从一开始就使用严格的相互TLS对其进行设置，并积极使用其强大的功能。具体操作请参考： https://istio.io/docs/setup/install/kubernetes/#installation-steps 为了使一切都有价值并且具有一定的性价比，我们需要在实际应用程序的上下文中考虑Istio，但是如果没有快速免责声明的话，最好不要这样做。如果你只需要管理少量服务（且位于单个集群内），那么引入Istio的性价比相对而言没有那么高。 本文中的代码示例不一定能够完全帮助你解决你的问题，但是如果你需要所有的代码以及如何使用它的详细说明都可以在GitLab上找到： https://gitlab.com/ContainerSolutions/k8s-deployment-mtl/ 接下来是你在Cloud Native旅程中可能遇到的两个常见问题，以及如何使用Istio来解决这些问题。 问题1：我不相信我的测试 如果测试范围并没有完全涵盖你所更改的应用程序，那么你可能会很快采取行动进行新一轮测试，但也有可能应用程序无法正常运行了。 在理想状况下，我们都想要确保每个代码经过全面的测试，否则就不会将功能添加到应用程序中。但是现实总归是骨感的，我们常常被ddl追赶，可能还未编写或者更新测试，功能就得上传到项目中了。 解决方案：放慢速度 那么，如何确保我绝大多数用户不受代码中潜伏的任何错误的影响，又如何进行更改和部署新功能呢？答案是通过先将新版本部署到最少数量的用户来最大程度地减少这些小问题的辐射范围。 如果更改能够按照预期工作的话，你可以缓慢增加使用新版本的用户百分比。如果各项指标出现问题，你可以轻松回滚你的更改，然后重试。 在没有Istio的情况下可以在Kubernetes上运行金丝雀部署吗？当然没问题，但是如果要自动化这一过程，你需要完全将自己的精力放在web服务器代码和自定义自动化脚本方面。这样的操作方式性价比并不高。 Istio有一些十分优雅的流量分配解决方案，我们可以使用它们在恰当的时间为合适的版本提供适当的客户端服务，并且我们只需调整其中的1个或2个参数。 为了实现这一点，你需要设置一个网关入口（Ingress gateway）、一个虚拟服务（virtual service）和一个destination rule。这将位于一般的部署和服务之上，并为你分配流量。 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: http-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hos ts: - "*" --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: my-app spec: hosts: - "*" gateways: - http-gateway http: - match: - uri: prefix: "/my-app" rewrite: uri: "/" route: - destination: host: my-app subset: v1 port: number: 80 weight: 90 - destination: host: my-app subset: v2 port: number: 80 weight: 10 --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: my-app spec: host: my-app subsets: - name: v1 labels: version: v1.0.0 - name: v2 labels: version: v2.0.0 从虚拟服务的权重字段中可以看到，Istio将根据指定的值在应用程序的两个版本之间分配流量。这些值的总和必须为100％，否则，API将拒绝应用该定义。 然后，你（或者理想情况下，在“持续集成/连续交付”流水线中手动执行一个或多个步骤）将调整权重，以将新版本推广给更多用户，直到所有请求由新版本满足为止，并且以前的版本可以停止维护。 通过使用Istio的故障注入功能来模拟网络中断和实际流量性能下降，还可以将Istio集成到您的集成测试策略中。 如果在生产中进行测试的想法给你留下了心理阴影，那一定是你的做法有所欠缺。例如，尝试在你的虚拟服务规范中添加以下代码片段以添加一些混乱，然后再找一篇文章来看看怎么用Istio解决这样的混乱。 spec: hosts: - my-app http: - fault: delay: fixedDelay: 7s percent: 100 route: - destination: host: ratings subset: v2 问题2：市场策略无法确定发布版本 通常，业务需要针对实际用户测试应用程序的多个版本。但是有时实在无法搞清楚是哪种营销策略可以带来最佳转化率，或者哪种设计选择可以带来最佳的客户留存率。 使用Kubernetes，你可以将流量分为两个版本，但是要想从练习中获得任何有价值的见解，则再次需要一大堆自定义代码来获取相关信息，并以非技术同事可以理解的方式对其进行处理。 解决方案：使用Istio进行A/B测试 Istio的流量分配规则可以再次解决这一问题，它与Prometheus和Grafana的紧密集成可以帮助你获取直观的A/B测试的结果。一般而言，根据传入数据包内容的某些部分，几乎有无数种方法来决定哪些用户可以获取你的应用程序的版本。 在这一示例中，我们将使用User-Agent字段为不同的浏览器提供不同的版本。 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: my-app spec: hosts: - "*" gateways: - http-gateway http: - match: - headers: user-agent: regex: ".*Chrome.*" uri: prefix: "/my-app" rewrite: uri: "/" route: - destination: host: my-app subset: v1 port: number: 80 - match: - headers: user-agent: regex: ".*Mozilla.*" uri: prefix: "/my-app" rewrite: uri: "/" route: - destination: host: my-app subset: v2 port: number: 80 从上面的代码中可以看到，使用Firefox的用户将获得应用程序的版本1，而Chrome用户将获得版本2。如果浏览器的“User-Agent”字段不包含“mozilla”或“chrome”，则他们都将不会获得任一版本。 要为其他客户提供服务，您需要添加一条默认路由，我将作为练习留给你。（嘿嘿） 如果你不想安装其他浏览器，只是想尝试一下，则可以使用带有头部标志的curl伪装成所需的任何浏览器，例如： curl /my-app -H "User-Agent: Chrome" 通过更改user-agent的值，你可以从命令行测试所有不同的路由。 总 结 以上两种情况大概能让你体验到Istio强大功能的冰山一角。正如上文所说，如果没有Istio，你依然可以进行金丝雀部署和A/B测试，只是你必须自己实现流量分配。但这大大增加了开发部署的复杂性，实属性价比低之选。 我希望这篇文章可以让你对Istio的实际应用有很好的理解，并且十分期待你自己尝试一下。如果你想了解更多关于Istio的信息，可以访问它们的官网，上面有许多有用的资料：https://istio.io/ 值得一提的是，Rancher 2.3 Preview2版本上开始支持Istio，用户可以直接在UI界面中启动Istio并且可以为每个命名空间注入自动sidecar。此外，Rancher简化Istio的安装和配置，内置了一个支持Kiali的仪表盘，用于流量和遥测的可视化，然后用Jaeger进行追踪，甚至还有自己的Prometheus和Grafana（与用于高级监控的实例不同）。这一切让部署和管理Istio变得简单而快速。 有关发行说明和安装步骤，请访问GitHub： https://github.com/rancher/rancher/releases/tag/v2.3.0-alpha5
2019-09-24

资源下载

更多资源
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册