标签: 实时数据

如今，关于微服务依然存在许多误解，企业盲目追求这种炫酷技术并不可取。同时，这种盲目行为对于希望用微服务来有效解决问题的公司很不利。不是说任何特定的技术都是缺乏实际价值的，如微服务、Kubernetes、Lambda函数之类的新技术是否被企业采纳，也许都取决于错误的理由。很多时候，企业可能只因为它比较流行就使用这些术语，却没有真正让它的技术优势在棘手的问题上发挥作用，或者提供切实可行的解决方案。从某种程度上说，它夸大了技术的实际作用，还给架构的合理选择和使用制造了障碍，这对于其他技术来说也很不公平。 因此，虹科想通过这篇文章来为大家一一澄清对于微服务所流传的五大误解。 微服务简介 微服务作为基础设施构建块提供了诸如服务解耦、数据存储自治、小型化开发和测试设置，缩短应用程序上线时间的优势。容器及其编排工具的可用性也提高了微服务的采用。每个微服务都是围绕一个特定的业务上下文——一个目标、焦点或问题领域。这些模块化的服务通过 API 进行通信，以便在应用程序中执行它们自己的功能。微服务应用程序的敏捷性、孤立性和专注性带来了显著的优势。包括： 1.团队授权： 小型独立团队可以快速部署代码，以非常敏捷的速度适应不断变化的要求； 2.灵活性 ：每个服务都可以使用最适合其独特需求的技术来构建； 3.可重用性 ：简单和模块化的代码是可重用的，可以应用于多种目的，以实现更快的开发； 4.隔离 ：隔离确保应用程序组件可单独操作和可扩展，并提供故障隔离，以防止微服务的 故障相互影响。 误解一：微服务可以解决所有问题 老话常说："当企业只有一把锤子的时候，一切看起来都像钉子"。如果微服务能帮企业解决实际难题，那自然好。但许多企业可能认为： 1.只要有应用场景，那么微服务就是解决方案。 Redis企业版数据库的合作伙伴解决方案架构师Lars Rosenquist建议：“首先，企业要搞清什么是微服务；然后，企业需要了解自己的应用架构出了什么问题；最后，才对两者进行匹配进行方案制定。但是很少人愿意真的这么做。” 2.多数技术只能解决特定企业规模的具体问题 。Lars Rosenquist解释说："如果是像Netflix这样的大公司，企业的应用消耗了三分之一的互联网流量，那就必须进行架构，才能使技术发挥作用。但如果企业是一家运营规模较小的公司，比如一家本地银行，那就不需要了。人们经常是在为他们想要解决的而不一定是真正存在的问题进行优化。” 3.大多数用例都不需要微服务。 编程专家建议：要尽量避免 "庞大的单体架构不好，庞大的单体架构是旧的解决方案"的心态，反之，企业在采用微服务方法之前，就应摒弃这样的错误认知。 误解二：微服务降低了复杂性 其实，微服务架构几乎都会增加复杂性。若不加以控制，它甚至还会变成一个分布式系统，使得架构更加混乱。因为： 1.微服务并不能解决系统设计问题。i DIA计算公司的软件开发顾问George Dinwiddie说：“如果企业不能创建一个具有高内聚低耦合的单体设计，那它很难把微服务做好。” 正如康威定律所言，先从一个单体开始，然后企业在增添开发人员时再去提取服务。Rosenquist认为："对于一个单体应用程序，它包含了所有的逻辑、通信和复杂性。通过微服务，企业却能打破这一常规。因为像通信模式之类的现在都属于企业基础设施的一部分。” 2.微服务不能消除复杂性。 微服务只是把复杂性移到了不同的抽象层，并没有真正让它消失。比方说，企业如果使两个应用程序组件处于同一个应用程序、同一个进程，甚至在同一个CPU中相互通信，那这个应用程序的速度一定是非常快的。但是对于微服务，这些应用组件被放在了不同机器上，它们之间相隔了一个网络，一整套基础设施，甚至可能是在不同的云中。这对于通信、故障模式及性能评估方面都会是非常大的挑战。” 使用虹科Redis企业版数据库，可以让管理复杂性变得更容易!但不要忽视复杂性是仍然存在的。 3.架构的复杂导致调试应用程序更加困难 。为了更好地管理这种复杂性，还需要确保企业的监控和可观察性工作做到位。尽管微服务方法可使企业的代码不再那么复杂，但 Rosenquist指出：“当要部署或管理它时，也许不再那么容易，企业现在并非只有一个而是有多个应用程序需要调试。这些应用程序在多个实例上运行，而这些实例也在整个架构中实现负载均衡。所有的这些通常都比使用单一的应用程序更为复杂。因此，要想实现成功部署，则需加强类似于日志聚合和可观察性之类事件的关注。” 4.不太复杂的代码并不一定能转化为不太复杂的系统。 Redis的开发领导者William Johnston指出"从代码的角度来看，单个服务可能更好理解，但企业用微服务创建的系统的复杂性会比单体复杂得多。"特别是在已经超负荷工作的小团队中，这也许意味着需要花费更多的开发时间。虽然能促使开发人员去学习应用领域和整个系统，但对于时间期限紧迫或缺乏技术经验的团队来说，微服务不可能“慢慢来”！因为微服务作为一种相当不同的操作方式，技术要求十分高。从长远看，整个系统的耦合度降低可以让重构更容易，但这也需付出很高的代价，并且开发人员的生产力可能会大幅下降，还可能影响对质量的保证。基于此，一个微服务依赖于这么多关系，它的测试难上加难。 Redis企业版数据库微服务可通过快速和灵活的数据模型降低复杂性 备注：康威定律是马尔文康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。 误解三：一种架构可以适用于一切 一种架构难以应用于企业的所有场景： 1.企业的旧应用程序可能不支持这些架构类型的模式。 企业也不应该认为自己可以立即开始重构旧的应用程序，要区分单体、微服务和函数。一个函数只做一件事，它们属于事件驱动型，是为特定的架构服务的。但在企业流程方面，如果企业分解掉所有的系统，最终会有一千个组件，企业也就不再具有优势。 2.最好的方法取决于具体的使用情况。 举个例子，一家银行很可能有相当多的单体系统。但为企业移动银行应用提供动力的微服务应用大约占到了50%-60%，其余的才是函数。因此，一家企业在架构方面应用场景是多样化的。 无论企业使用的是什么软件架构或模式，一个优秀的工程团队都要学会找到最有效的方法。 单体与微服务架构的比较 误解四：微服务主要是一种技术 1.实际上微服务解决的是一个业务或组织的可扩展性问题。 Johnston指出："微服务解决的是一个技术问题，如果未达到这个目标，那就是浪费时间。很多人甚至是部分大型企业启动一个新的应用程序时，都认为他们需要从分离领域的方式及微服务开始，但如果企业对业务领域没有一个明确的定义，就不该从微服务开始。” 再一次引用康威定律，企业软件环境中和组织整体中的通信模式是相似的。 Rosenquist认为："假设企业想从一个单体架构转换到一个微服务架构，应先建立在本身的组织架构上。比如，将团队分开，确保每个微服务属于其中一个团队，这其实是一个管理问题，而非一个技术挑战。” 2.应当确保每个人都理解微服务的含义，以及该技术解决业务问题的方式。 不同部门对微服务的本质往往有不同的看法。采用微服务架构是否能获得优势取决于这个问题的大小以及采用该技术的团队本身。 误解五：微服务允许团队使用他们喜欢的技术 这其实并不完全是一个误解，因为对团队来说，使用不同的平台并不总是一个好主意。 Johnston认为：“人们普遍认为可以使用他们喜欢的语言、工具和平台，这是微服务的一个优势。但如果企业团队很大，甚至有分布在世界各地，比如，一些团队可能擅长.NET，而另一些则擅长Java。那么对于他们特定服务的业务领域，使用某种特定技术可能对他们有利。”然而，Johnston提醒说：“对额外环境的开发是以增加系统的复杂性为代价的，企业架构师也需要了解系统的复杂性。 " Rosenquist建议："企业可以为每个微服务选择不同的技术，但如果企业有500个微服务，仅使用5种技术会更好而不是500种不同的技术。”当然，这些都是例子，没有一个放之四海而皆准的方法，企业应当在管理和加大开发复杂性之间找到平衡点。 关于微服务的误解众多 以上是我们分享给大家的关于微服务流传较广的误解，但并不仅限于此。虹科云科技在这里也为大家整理了一些其他关于微服务的误解： 1.微服务能加速业务 。Johnston建议："由于网络跳转的增加，微服务会引发速度下降。企业必须接受最终的一致性，但在其他类型的应用程序中企业可以不需要这么做。” 2.微服务实际上是很小的。 技术咨询公司Archium的联合创始人Graham Le提到：“不要被微服务中的【微】所迷惑。微服务应该比单体小，但最理想的是，一个服务能覆盖一个中等规模的领域。小只是一个相对的术语；但重点不是让他们变得非常小。” 3.每种客户端都需要对应一个微服务。 咨询公司Blue Herring的DevOps架构师Mark W. Schumann表示"这种想法是错误的，但他们一直在这样认为！与之相反，应该考虑每个资源对应一个微服务"。 Redis企业版可以解决的微服务问题 作为一个多租户解决方案，Redis Enterprise 企业在微服务之间隔离数据。最重要的是，它允许用户对数据库进行调优，以在性能和数据一致性/持久性之间保持权衡。Redis企业版数据库还可用于将实时性能扩展到缓存之外的一些微服务用例，如；服务内通信和事件源，也通常被用作支持单个微服务的轻量级数据库。Redis企业版数据库在微服务方面主要具有以下优势，为客户提供最全面的解决方案： 1.降低系统复杂性。 每个Redis 企业版数据库缓存的各个方面都可以为每个微服务定制，提供简化的管理，以减少微服务架构带来的操作复杂性。 2.提供实时速度更快的微服务。 所有的网络延迟都会降低应用程序的性能。Redis企业版数据库提供了一种方法来收回服务间通信损失的大部分时间，具有数据查询和消息传递的亚毫秒性能，让微服务应用速度更快。 3.多租户支持。 多租户违背了微服务完全隔离单个应用组件的做法，因此，系统经常遇到争夺资源的挑战，个别服务可能过度消耗其他微服务共享的资源。用户可以在Redis企业版数据库安装上为所有微服务部署多个数据库实例，而且数据在数据库之间保持隔离。Redis企业版数据库的内置机制通过触发重新分片或跨节点移动来平衡吞吐量/延迟，从而保护实例不受影响。 4.高可用性与自动故障检测。 Redis企业版数据库的架构提供了自动故障检测和零停机时间扩展，对使用它的微服务完全透明。故障检测和故障转移可以在几秒钟内完成，并且不会丢失数据，高度可靠、随时可用。 5.原生 Kubernetes 容器编排和管理。 用户可以在 Kubernetes 环境中把 Redis企业版数据库容器作为云原生数据库服务进行协调。二者集成可以实现多种功能。 6.支持多种部署模式。 无论用户的微服务是在私有云环境、企业内部还是在云中运行，Redis企业版数据库的灵活部署选项都能让微服务尽可能地接近数据，并使用户可以完全控制它的数据。 虹科Redis企业版软件（Redis Enterprise）是企业级的数据库软件，也是一款实时数据平台，为全球超过8500家知名企业提供实时数据服务。具有 线性可扩展性、高可用性、持久性、备份和恢复、地理分布、分层内存访问、多租户、安全性 等8大核心功能、拥有RediSearch、RedisJSON等7大【Redis企业版特有模块】，可以任何规模在云、本地和混合部署中运行现代应用程序，提供无服务器、多模型的数据库解决方案。Redis企业版的核心优势是采用Redis on flash分层存储技术即【内存+闪存+磁盘】的存储方式，其Active-Active地理分布式架构允许跨地理位置同时进行数据读写操作、拥有亚毫秒延迟和极高吞吐量。 虹科是Redis企业版的中国区战略合作伙伴，若感兴趣白皮书： 《Redis Enterprise 如何用于微服务缓存》 ，以及关于如何消除微服务存在的问题有任何其他疑问，欢在评论区进行交流或者联系我们！

导语：开源数据无处不在，但是在许多情况下，它们的格式多种多样，不仅仅是以Excel形式，如xml、JSON，因此并非所有潜在用户都可以访问数据。这意味着只有具有相关数据知识基础 的用户才能查询信息并提取有价值的数据结论。 举个例子：欧盟开放倡议使得许多政府在其门户网站上公布其大量数据。下面是相关链接： http://www.arso.gov.si/xml/zrak/ones_zrak_urni_podatki_zadnji.xml 该数据集包含斯洛文尼亚每隔1小时的最新污染物测量值。该网站定期更新，但是新的数据记录取代旧记录。其中产生了两个问题，第一是当前值与之前的测量值无法进行比较，第二是无法进行数据前后关联获取相关联系。也就是说，与某些标准相比，当前的污染物测量值是低还是高，无从得知。 如果没有这种评估，普通市民就无法确定他们所在城镇的空气是否干净，是否应该让孩子留在室内，并在污染高峰前关闭窗户。 一、创建自动化数据采集工作流 我们将使用文件块（黄色块）直接从URL中收集数据，然后重命名并格式化日期和其他字段（紫色字段管理器块），然后将记录存储在IOD中以附加模式输出文件（绿色块）。 接着使用管理部分中的调度应用程序，每 3 小时自动收集和存储一次数据。通过执行一些常规的重复数据删除操作，可以在同一个项目中将同一归档数据文件块可视化(绿色区域中的黄色块)。 数据刷新也会更新蓝色Report块，使得新数据可以立即反映在交互式图表中。 黄色文件块配置如下： 二、使用过滤器和KPI视图构建动态仪表板 下面介绍比较有趣的部分：收集和清理数据，并将数据可视化！ 选择图表一直是数据可视化中的一个挑战，但为了最大限度地减少迭代，我们将添加一个变量“度量选择”，以便报表查看器可以循环查看KPI，并比较各个位置之间的平均水平，以便观察每小时的波动情况。注意：所有的这些可视化情况都可以在一个页面上展示！ 单击一个或多个条行框将产生“刷新效果”，其中未选择的值将消失，但仍会存在，以供进行基准测试。这就是“移动”和“保留”按钮，除了过滤功能外，这个功能可以用户能够只保留感兴趣的数据点。 中间的文本选择变量是在“报告数据源”区域（“度量选择”）中创建的，而IF公式将协调5个度量之间的切换。 如果查看者选择“CO”作为他们的比较标准，页面上的所有图表都将指向该输入的“测量”字段，因此折线图、条形图和标记将根据CO的级别比较不同的位置。内容视图将进行更新，同时提取出最大值并确定记录该测量的位置。 这是带有“变量切换公式”的公式块： IF( ="co", , ="no2", , ="o3", , ="pm10", , ="pm2.5", , ) 下面展示如何构建交互式KPI视图： 内容视图是一个非常价值的报表工具，因为它可以将动态文本与响应公式结合起来。产生的结果文本将随着每次数据更新和每个查看者的交互而变化（只要“查询”部分指向“过滤数据”）。 根据查看者的不同选择，小部件将根据世界卫生组织的每日限制显示指导，并提供指向相关网页的URL链接。 以下数字“92”背后的公式—评估该期间各污染站的污染物最大测量值： IF( SUBSET_MAX( )=null,"no measurements", SUBSET_MAX( ) ) 以下是污染物测量值最高位置名称背后的公式（考虑到多个位置可以记录相同结果的可能性）： SUBSET_UNIQUESLIST( , SUBSET( ,(SUBSET_MAX( )))) 我们还可以将最大值文本颜色链接到一个函数，这样它就可以动态响应评估结果，指示测量的级别是否高于允许值。 IF( SUBSET_MAX( ) - IF( ="pm10",45, ="pm2.5",15, ="no2",25, ="o3",100, ="so2",40, ="co",35, null) 0,"red","green") 同样，我们可以在折线图中创建“动态参考线”，并将其链接到变量选择。 IF( ="pm10",45, ="pm2.5",15, ="no2",25, ="o3",100, ="so2",40, ="co",35, null) 如果我们希望比较不同时期的污染物所在位置（过滤设备的时间范围为24小时、1周、1个月），并评估它们的水平是否高于或低于规定的限制，则整个可视化效果会很好。 群众可能想知道哪些污染物位置受到一种或多种污染物的影响？这个问题，我们同时将位置与所有5个KPI 进行比较，可以在雷达图窗格模式下开展这项工作并在可视化窗口进行位置观察。 在这种模式下，雷达不用于精确测量，而是作为一种分析工具来标记哪个位置存在一种或多种污染物的问题。 三、选择报表样式并进行润色 最后一步是查看报告设置中的样式部分。选择好看仪表板背景和颜色能够使可视化界面更加美观醒目。在本案例中，背景是浅蓝色的，以清新空气为主题。“创建样式”是创建双色样式的快捷方式，包括1个背景，1 个前景。 可以通过键入 Google 字体名称或从链接中复制来选择字体，在下面的示例中，我们选择了“Questrial”。 在同一页面上，有3种颜色设置方法： 选择默认数据颜色 单击“分配颜色”，对每个字段中的值使用随机分配 通过单击左侧边栏数据菜单中的数据值旁边的颜色方块，手动选择颜色 书签菜单，将其添加到不同的项目中。