首页 文章 精选 留言 我的

精选列表

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

5个规则，确保你的微服务优化运行

云栖号资讯：【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 最近几年好像大家都开始对微服务着迷，与此同时单体架构也在慢慢淡出人们的视线。 当然，热门的趋势总是来来去去，而且它们所受到的关注往往被媒体夸大了，实际情况并不总是如此。不过，对于微服务来说，人们似乎已经达成共识，认为这个趋势会一直存在下去。这是有道理的。从概念的角度来说，微服务扩展了工程师们几十年来采用的相同原则。 一旦你开始使用微服务架构，也许你需要本文中提到的5个规则，帮助你成功运行它们。 微服务的另一面 关注点分离(SoC)是一项设计原则，规定软件的构建应根据 "关注点 "或总体功能来确定不同的部分，30多年来一直被用来决定如何构建技术。在单体应用中，它体现在典型的3层架构中的表现层、业务层和数据层的分离。 微服务采用了这个概念，并将其颠覆。它们将同一个应用程序以这样的方式分离出来，应用程序的单一代码库可以被分解并单独部署。这样做的好处是巨大的，但也是有代价的，通常体现在时间和金钱两方面的运维成本较高。除了将现有的应用程序过渡到容器所带来的巨大的前期投资之外，维护该应用程序也带来了新的挑战。 挑战1：似乎很难监控整体 虽然单体应用程序也有其自身的挑战，但在单体中回滚一个“坏”版本的过程是相当简单的。在容器化应用中，事情就变得复杂许多。无论你是将单体应用逐步分解为微服务，还是从头开始构建一个新系统，你现在都有更多的服务需要监控。其中每一个都可能会： 使用不同的技术和/或语言。 运行在不同的机器和/或容器上 使用K8s或类似的技术进行容器化和编排 随之而来的是，系统变得高度分散，更需要集中监控。遗憾的是，这也意味着需要监控的东西也多了起来。以前只有一个单体进程，而现在可能有几十个容器化进程运行在不同的区域，有时甚至是不同的云。这意味着不再有一套单一的运维指标来统治它们，IT/运维团队可以用它来评估应用程序的一般正常运行时间。取而代之的是，团队现在必须处理数以百计（甚至数以千计）的指标、事件和告警类型，他们需要从中分离出有效信号和无效噪音。 解决方案 DevOps监控需要从扁平化的数据模型转向分层模型，在这种模型中，可以随时观察到一系列高级系统和业务KPI。只要有一点偏差，团队就必须能够进入指标层次结构，查看干扰来自于哪个微服务，并从那里了解实际发生故障的容器。这很可能需要从数据存储和可视化的角度重新调整DevOps工具链。开源的时序DB工具，诸如Prometheus和Grafana 7.0等使得这个目标非常容易实现。 挑战2：跨服务日志记录 在谈论监控应用程序时，首先要提出的事情之一是：日志、日志、日志。服务器每天都会产生的IT日志相当于碳的排放量，最终导致溢出的硬盘驱动器以及疯狂摄取、存储和工具成本。即使采用单体架构，你的日志也可能已经使你的工程师有些头疼。 使用微服务，日志变得更加分散。一个简单的用户业务现在可以通过许多服务进行，所有这些服务都有自己的日志记录框架。要解决问题，你必须从业务可能通过的所有服务中提取所有不同的日志，以了解问题所在。 解决方案 这里的主要挑战是了解单个业务如何在不同服务之间“流动”。为了实现这一点，需要对传统的单体程序在顺序业务执行期间通常如何记录所有事件的方式进行大量修改。尽管已经出现了许多框架来帮助开发人员进行处理（我们特别喜欢Jaeger的方法），但对于希望将单体重构为微服务的企业而言，转向异步、跟踪驱动的日志记录仍需要付出艰巨的努力。 挑战3：部署一项服务会破坏另一项服务 单片机世界中的一个关键假设是，所有代码都是在同一时间部署的，这意味着应用程序处于最脆弱状态的时间范围是一个已知的、相对较短的时间段（即部署后的前24-48小时）。在微服务的世界里，这个假设不再成立：由于微服务本质上是相互交织的，其中一个服务细微的变更可能会导致行为或性能问题，而这些问题会在另一个服务中体现出来。因此所面临的挑战是，当前出现故障的微服务使得另一个开发团队并没有预料到他们的代码会出现中断。这既会导致整个应用意外的不稳定性，也会导致一些组织内部的摩擦。虽然微服务架构可能让部署代码的过程变得更容易，但实际上却让部署后验证代码行为的过程变得更难。 解决方案 企业必须创建共享的发布日历，并且每当部署相关的微服务时，都要分配资源用于密切测试和监控整个应用的行为。在没有跨团队协调的情况下部署新版本的微服务，就像牛油果加吐司一样，是解决这一挑战的成功秘诀。 挑战4：难以找到问题的根本原因 在这一点上，你已经锁定了有问题的服务，提取了所有需要提取的数据，包括堆栈跟踪和日志中的一些变量值。你可能还有一些APM解决方案，比如New Relic、AppDynamics或Dynatrace。从那里，你会得到一些额外的数据，关于一些相关方法的异常高处理时间。但是......问题的根本原因呢？ 你（希望）从日志中得到的前几位变量数据很可能不会是那些移动针的数据。它们通常更像是面包屑，指向下一条线索的方向，而不是更进一步的原因。在这一点上，我们需要尽我们所能，发掘出更多应用程序下的 "魔力"。传统上，这需要发出关于每个失败事务状态的详细信息（即到底为什么失败）。这里的挑战是，需要开发人员具有巨大的预见性，以知道他们需要哪些信息来提前排除问题。 解决方案 当微服务中的错误根源横跨多个服务时，制定一个集中的问题根源检测方法至关重要。团队必须考虑需要哪些信息颗粒来诊断未来的问题，以及它们应该在什么层级上发出日志，以考虑到性能和安全因素——这是一座高高的山，而且是一座永无止境的山。 挑战5：版本管理 我们认为值得强调的问题是，从典型的单体架构中的层模型过渡到微服务的图模型。由于超过80％的应用程序代码通常是第三方代码，因此在公司的不同微服务之间管理第三方代码的共享方式成为避免陷入前所未有的“依赖地狱”的关键因素。 考虑这样一种情况：一些团队在使用第三方组件或共享实例程序的X.Y版本（几乎所有公司都有），而其他团队则使用X.Z版本。这就增加了由于不同版本之间缺乏兼容性而产生的关键软件问题的风险，或者说，不同版本之间行为的轻微变化，可能会导致需要排查最特异和痛苦的软件bug。 而在这一切之前，我们还要提醒自己，任何一个微服务使用第三方代码的旧版本、更脆弱的版本，都会产生安全问题——这是黑客的天堂。允许不同的团队在孤岛般的repo中管理他们的依赖性，在单体世界中可能是可行的，但在微服务架构中，这是绝对不可以的。 解决方案 公司必须在重新设计他们的构建流程方面进行投资，以便为第三方和共享实用程序代码利用集中式artifact仓库（Artifactory将是其中之一）。团队应该只允许将自己的代码存储在单独的仓库中。 最后的思考 与科技行业的大多数进步一样，微服务采用了一个熟悉的概念，并将其颠覆。它们重新思考了大规模应用的设计、构建和维护方式。它们带来了许多好处，但也带来了新的挑战。当我们把这五个主要挑战放在一起看时，我们可以看到它们都源于同一个理念。因此，每当采用像微服务这样的新技术时，底线是既需要重新思考，也需要重新调整代码的构建、部署和观察方式。微服务所带来的优势是难以拒绝的——但风险也是巨大的。 【云栖号在线课堂】每天都有产品技术专家分享！课程地址：https://yqh.aliyun.com/live 立即加入社群，与专家面对面，及时了解课程最新动态！【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK 原文发布时间：2020-07-23本文作者：Rancher本文来自：“dockone，了解相关信息可以关注“dockone”
2020-07-23
优秀的个人博客,低调大师

深度 | X-Engine的In-Memory读性能优化

背景 虽然同为LSM-tree架构，X-Engine的设计哲学与传统基于LSM-tree架构的Rocksdb等引擎并不完全一致，如下图所示： 设计关键点1：X-Engine磁盘上的数据，在常态下只有两层（L1/L2），L0层是MemTable在compaction来不及的情况下暂存到磁盘上缓解内存压力时才启用的，正常情况下被冻结的MemTable可以直接和磁盘上的L1合并。 设计关键点2：在L1/L2之间的compaction合并过程中，X-Engine的冷热合并算法倾向于将热点数据保留在L1层(基于访问频度），将访问较少的数据下刷到L2层并进行压缩存储。这是一个对数据在物理上进行冷热分离的过程， 其结果是L1存储的都是热点数据，L2存储的都是冷数据。对L1进行缓存时会有更高的内存利用率。 按照设计初衷，X-Engine正常运行时，Mem
2020-06-28
优秀的个人博客,低调大师

不会搭建大数据平台，我被老板优化了...

在业务增涨过程中，每个企业不知不觉积累积累了一些数据。无论数据是多是少，企业都希望让“数据说话”，通过对数据的采集、存储、分析、计算最终提供对业务有价值信息。 此时，大数据平台的搭建就是企业面临的问题，搭建大数据平台有哪些思路？怎么样的搭建路径可以让企业少走弯路？什么样的架构是业内标准？通过什么手段来分析和展示已有的数据？ 或许这些问题会萦绕在您的心头，那么今天就一起来看看如何解答它们吧。 大数据平台的搭建思路 实际上做任何事情都要有目标，然后根据这个目标根据自身的条件和外部的情况制定一个思路，这个思路也可以理解为实现目标的路径。那么大数据的平台搭建也不例外。 脚本工具化 在数据收集，存储、分析的初期，通常来说程序员都是根据业务需求，通过一些脚本来完成数据收集，分析的工作。 表面上是完成了一些数据操作的功能，同时也满足了用户的需求，但是在编写脚本的时候，都是“头疼医头脚疼医脚”，只是针对具体的数据问题提出解决方法。 没有一个统一的解决方案，针对一些基础通用的功能也没有做抽象和提取，导致脚本维护的成本增加，后期服用的成本也会增高，有重复造轮子的嫌疑，效率不高。 因此，我们会讲这些脚本组件包装成一个个工具，用命令行或者 UI 界面的方式提供给客户。 这样一来，脚本的经验得到了总结和提炼，整个工具考虑得会比组件更加周到，效率有所提高。 工具服务化 有了工具可以满足一些数据上的需求，但是由于工具运行在本地无法发挥公用的特性。 为了让工具被更加广泛的使用，于是将其以服务的方式发布的云端，此时业务人员可以在有网络的地方访问到大数据工具，从而实现计算和分析工作，打破了地域的限制。 服务平台化 既然有了服务上云，那么将这些服务做一些聚合的操作，让相关联的服务互相沟通产生“化学反应”，从而给用户带来更大的价值。 同时可以将多个数据源都接入到平台中，利用这些服务提供给客户更高的价值。 此时，数据源，服务，客户需求都是不同的，那么通过平台进行整合，从而显示出更大的威力。 现在流行的 SAAS 系统就是一个很好的例子，采用多租用户的方式，整合资源提供优质的数据服务。 平台产品化 既然产生了一个大数据的平台，整合了数据、服务、需求（客户）各个方面的资源。 如果继续发展就需要针对不同的用户需求建立不同的业务场景，由于行业不同、企业内部和市场环境不同，大数据的应用场景也千差万别。 此时如果还提供统一的数据服务恐怕就不合时宜了，那么此时需要针对行业以及细分领域进行业务服务的客制化。 针对一些行业底层的业务进行抽象和拆分，给用户更多的客制化空间，针对不同的行业和使用场景退出不同的大数据产品，给到用户。图 1：大数据平台指导方针 从脚本到工具，服务、平台、产品的转化不仅是大数据平台发展的进程和步骤，同样也是不同规模企业进行大数据平台搭建的准绳。 为什么这么说呢？技术始终是为业务服务的，大数据平台平台也是如此，只要让数据产生对企业有正向推动力就是正确的方向。 在最开始的时候，就可以通过脚本的方式进行实验和试错，积累数据分析抽取的经验，从而得到一些对业务有价值的数据信息。 后面通过不断迭代和试错，将这些经验从脚本→工具→服务→平台→产品进行转换。 这样以终为始，即减少了开发走的弯路，也提高了效率，最重要的是做出来的东西是有价值的，老板的投入看得见。 每个企业也可以根据自身情况选择对应的切入点，不用做大而全的大数据平台，做适合自己的就好。 大数据平台的建设路径 说了建立大数据平台的基本思路以后，我们知道针对不同的企业业务规模以及不同的发展阶段，可以选择适合自身的大数据平台建设思路。 那么这里就说说如何建立大数据平台，怎样的建设路径能够帮助我们落地大数据平台，这里分两个方面讨论。 针对业务场景的建设方式 正如上面提到的以终为始的思路，针对企业面对的具体业务场景建立大数据平台，让数据针对具体的业务发挥作用，是最能够体现数据价值的。 例如：企业需要做拉新的线下活动，假设这次拉新 1 万人。针对的群体是学校的学生，那么需要多少花多长时间，在多少个学校，摆出多少个展位才能达到效果。这些都可以通过企业系统中现有的数据进行分析，得到结果。 因此这种方式的优点是 :和具体业务结合紧密，业务逻辑可以根据企业业务状况进行定制，从而最大限度匹配需求。技术开发人员与业务人员的交互效果和业务复杂度可控，甚至是无缝对接，基本屏蔽与业务无关的内容，确保易用性。业务人员定义的需求，使用者就是业务人员本身。 专业对口，不考虑平台通用性问题，也不用考虑与其他平台、应用的对接。整体平台用时短，成型快，效果明显。 这种方式的缺点是:仅限于固定的业务场景拓展性差，对整个行业和系统缺乏统筹考虑。可能会做重复建设的工作，从长远来看开发效率不高。 通用组件的建设方式 “通用”顾名思义，将大数据平台中通用的功能抽离出来，通常这些功能和具体的业务实现无关。 无论什么业务场景都会用到的，例如：数据收集、数据导入、数据计算、数据搜索、数据展示等。 让后在这些基础功能/模块的基础上进行业务功能的封装，其目的很明确，为了更长远的业务发展做准备。 此类建设方式不仅关注当前业务的落地，更关系以后不同业务场景，不同行业的平台扩展。 这种方式的优点是 :通用功能作为大数据平台的基础，可以针对不同业务场景进行拓展。同功能避免重复造轮子，将技术功能和业务需求进行解耦。对于架构设计考虑会更多，对行业的理解会更深，对使用场景的考虑会更多。 这种方式的缺点是：架构设计难度大，考虑因素多，开发周期长。架构中模块关系负载，开发复杂度高。对业务的抽象能力有要求，需要一个或者多个行业的丰富经验，业务理解成本较高。 上面两种基于业务和通用组件的建设方式各有利弊。在企业进行搭建大数据平台的时候，需要根据自身的情况进行抉择。 如果是大数据刚刚起步的企业建议使用前一种方式，边做边摸索，边总结边重构，最终过度到第二种方式。 如果说企业在大数据平台技术和业务上都有了深厚的积累，则可以考虑从更高的视角，切入第二种方式。 大数据平台的实现架构 说了大数据平台的思路和实现路径以后，再来从技术架构的角度来看看如何落地。 有的企业会借鉴其他企业的成功案例，有的企业会根据自身情况进行摸索。笔者在这里给出的建议是依托方法论，结合企业实际情况，参照行业经典案例进行构建。说起来有点虚，来看看具体的架构实现。 Lambda 架构 Lambda 架构（Lambda Architecture）是由 Twitter 工程师南森·马茨（Nathan Marz）提出的大数据处理架构。 这一架构的提出基于马茨在 BackType 和 Twitter 上的分布式数据处理系统的经验。图 2：Lambda 架构示意图 如图 2 所示，Lambda 共分为三层，分别是批处理层（Batch Layer），速度处理层（Speed Layer），以及服务层（Serving Layer）。 下面来看看他们分别有什么作用：批处理层（Batch Layer），存储管理主数据集和预先批处理计算好的视图。这部分数据对及时性要求不高，会采取批处理的方式同步到主库中，通常以定时任务的形式存在。速度处理层（Speed Layer），会处理实时数据。由于对数据及时性的要求，这部分数据会通过内存计算出结果，马上提供给使用者，同时对于数据的准确性要求也不高。会通过批处理层入库以后针对部分数据进行校验，通常以 Storm 之类的应用的形式出现。服务层（Serving Layer），数据进入到平台以后，会进行存储、同步、计算、分析等过程。但是，最终都是需要提供给用户使用的。由于用户使用的方式和业务试图的差异性，需要有一个服务对其进行权衡。服务层就应运而生了，它主要负责以服务的方式将数据提供给终端客户，其形式有报表、仪表盘、API 接口等等。 如果说 Lambda 架构是方法论的话，那么每个企业会根据其建立自己的大数据平台，从架构方面来看，都大同小异。图 3：大数据平台技术架构 如图 3 所示大数据平台由上到下，可分为：数据采集数据处理数据输出与展示 ①数据采集 这里包括从多个源头收集数据信息，例如：浏览器、移动设备、服务器日志文件。 再将这些信息数据和日志等同步到大数据系统中，注意同步的过程需要考虑数据源和数据结构的差异。 同步会使用 Sqoop，日志同步可以选择 Flume，行为数据采集经过格式化转换后通过 Kafka 等消息队列进行传递。 这些数据在解决了数据源和数据异构以后，还需要进行数据清洗，特别是日志和爬虫数据，需要提取对业务有意义的数据进行存储。 ②数据处理 同步的数据存储在 HDFS 之类的分布式数据库中。可以通过 MapReduce、Hive、Spark 等计算任务读取 HDFS 上的数据进行计算，再将计算结果写入 HDFS 或者其他库。 这里会根据数据的及时性分为离线计算和实时计算，刚好和 Lambda 中的批量处理和速度处理相对应。 比如针对用户的购物行为进行关联性数据挖掘，这时候数据量大、逻辑复杂，需要较长的运行时间，这类计算可以使用离线计算来处理。 另外对处理时间敏感的计算，比如双 11 每秒产生的订单数，为了及时地展示和监控，会采用流式计算。 通常用 Storm、Spark Steaming 等流式计算引擎完成，可以在秒级甚至毫秒级内完成处理。 ③数据输出与展示 有了采集和处理就一定会面对输出和展示。一般来说通过应用程序直接访问数据库来完成数据展示。 由于对于业务、市场、管理的复杂性，对外需要展示客户、竞争对手、产品的信息；对内需要根据操作层、管理层、决策层进行数据的聚合和汇总。对数据输出和展示有一定要求。后面我们会针对这部分进行展开说明。 由于通过上面三个部分需要写作完成采集、同步、存储、计算、展示的工作，因此需要任务调度管理系统对其进行协调调用。 大数据平台驱动业务运营 前面我们说了如何在企业中落地大数据平台，其中提到了以终为始的概念，大数据平台最终还是需要为业务运营系统提供正向推力的。有了大数据平台就需要用好它，从中挖掘出更多的商业价值。 通常的情况是这样的，根据公司战略目标以及公司目前的能力和外部的威胁和机会，公司会定义一个战略思路。 这个是公司发展的纲领，围绕这个战略纲领业务部门和运营部门对其进行分析和拆分，生成业务需求，然后从这个业务需要推到出需要哪些关键要素（节点）。 再来看这些关键要素需要哪些数据为其进行决策和支撑。最后，将这些要素变成业务需求提交给产品团队进行分析，然后交由大数据技术团队完成对应的功能。图 4：大数据平台驱动业务运营 从思考过程来看是现有业务再才有大数据平台的功能，但是从执行层面来看。 为了实现业务的功能业务人员是先要到大数据平台上面获取对应的信息，再才能实现业务决策和行为。 例如上面提到的拉新的例子，业务人员为了达到拉新 1 万人的目的，会先到大数据平台搜索。 针对产品的受众，偏好、价格、沟通方式、市场、促销等方面的问题，获取对他们有价值的信息，例如：在哪些学校、针对什么年级的学生、开辟多少展位完成这次活动。 因此在执行过程中是大数据本身的价值在驱动业务前行的。思考和行动在方向上正好相反。 数据可视化平台的实践 既然要对企业的主要业务进行驱动和推动的作用，那么就不得不提到大数据平台的可视化以及展示功能了。 作为可视化的大数据平台需要从以下几个方面进行实践： ①用户管理与权限 平台的建立是为用户服务的，首先要标定服务的用户。由于用户的多样性，有的是企业内部客户，有的是合作伙伴，还有终端用户。 因此需要考虑：用户的权限和角色管理。业务分组功能，针对业务分类、子分类对用户进行划分。根据数据功能进行不同的安全等级管理，包括流程管理。支持对原数据的检索和浏览。 ②多样化的产品功能 由于使用者的不同，导致面向的业务场景也会有所不同。那么针对不同的业务场景就要展示不同的数据输出：提供多种图表、报表功能。针对图表、报表提供自定义字段、过滤器功能。增加组织视图和个人视图从不同角度审视数据。 ③对其他系统的集成功能 即便大数据平台已经整合了企业级别的各种数据，拥有多种数据源，但是依旧存在短板。 如果针对其他业务系统或者生产系统进行整合，通过功能、数据集成，让数据产生关联便会产生更大的能量：集成企业、上下游、供应链 ERP 系统。与行业数据、国家经济指标进行结合。与通用的邮件、通知、效率系统进行集成。 总结 从大数据平台搭建思路作为切入点，通过脚本、工具、服务、平台、产品几个递进的阶段，描述了企业在不同的发展阶段可以采取不同的思路。 如果说有了思路，那么在执行的有两种方式：业务场景和通用组件来进行。 落地到大数据平台架构的时候，利用 Lambda 架构的方法论，进行数据采集、处理、展示。大数据平台是为业务创造价值，反过来通过平台也可以驱动业务的发展。 通过数据库可视化平台的实践，让业务人员通过多样的数据功能和大数据平台产生链接，最终产生商业价值。
2020-05-30

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2025-12-12 大小: 211.28KB 下载: 54次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-03-01 大小: 1MB 下载: 6次
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-03-02 大小: 1.42GB 下载: 3次
Sublime Text

Sublime Text

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

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

欢迎您来访！

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

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

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册