DynamoDB

点击上方蓝色“ 程序猿DD ”，选择“设为星标” 回复“ 资源 ”获取独家整理的学习资料！ 作者 | linkt1234 来源 | https://blog.csdn.net/Linkthaha/article/details/100575278 最近，在对公司容器云的日志方案进行设计的时候，发现主流的ELK或者EFK比较重，再加上现阶段对于ES复杂的搜索功能很多都用不上最终选择了Grafana开源的Loki日志系统，下面介绍下Loki的背景。 背景和动机 当我们的容器云运行的应用或者某个节点出现问题了，解决思路应该如下： 我们的监控使用的是基于prometheus体系进行改造的，prometheus中比较重要的是metric和alert,metric是来说明当前或者历史达到了某个值，alert设置metric达到某个特定的基数触发了告警，但是这些信息明显是不够的。我们都知道，k8s的基本单位是pod,pod把日志输出到stdout和stderr,平时有什么问题我们通常在界面或者通过命令查看相关的日志,举个例子：当我们的某个pod的内存变得很大，触发了我们的alert，这个时候管理员，去页面查询确认是哪个pod有问题，然后要确认pod内存变大的原因，我们还需要去查询pod的日志，如果没有日志系统，那么我们就需要到页面或者使用命令进行查询了： 如果，这个时候应用突然挂了

边看边听真舒服，人生短短几个秋... 倚天屠龙记中 赵敏 郡主携带一帮高手围攻武当，武当派掌门 张三丰 被暗算，传了一套武功给 张无忌 用来对付赵敏的手下。这套武功就是 太极拳 。 ❝ 张三丰 ：无忌，我教你的还记得多少？ 张无忌 ：我全忘了！ 张三丰 ：很好，你只要记住把玄冥二老打趴下就可以了。 上篇 用 三国杀 讲分布式中的拜占庭将军问题，还挺有意思的，这次我们用 倚天屠龙记 中的 太极拳 来聊下剩下的 三大理论 ： CAP 理论 ACID 理论 BASE 理论 ❝ 太极拳的精髓：以柔克刚，刚柔并进，四两拨千斤，无招胜有招。 我把 CAP 理论称作 太极 ，ACID 理论称为 阳 或 刚 ，BASE 理论称为 阴 或 柔 。ACID 理论追求一致性，BASE 理论本来就叫做柔性事务，追求的是可用性。那张无忌为什么会全忘了还打败了玄冥二老呢？因为太极拳的精髓是拳意，无招胜有招。 1、太极的两面 CAP 理论是对分布式系统的特性做了一个高度的抽象，变成了三大指标： 一致性（Consistency） 可用性（Availability） 分区容错性（Partition Tolerance） 分布式中的一致性，我们可以理解为客户端的每次 读操作 ，不管访问的是哪个几点，要么读到的都是同一份最新写入的数据，要么读取失败。这就很刚了，不能说这种 刚 不好，在很多场景中

“Serverless 能取代微服务吗？” 这是知乎上 Serverless 分类的高热话题。 有人说微服务与 Serverless 是相背离的，虽然我们可以基于 Serverless 后端来构建微服务，但在微服务和 Serverless 之间并不存在直接的路径。也有人说，因为 Serverless 内含的 Function 可以视为更小的、原子化的服务，天然地契合微服务的一些理念，所以 Serverless 与微服务是天作之合。马上就要 2021 年了，Serverless 是否终将取代微服务？从微服务到 Serverless 需要经过怎样的路径？本文将对 Serverless 与微服务在优势劣势上进行深度对比。 从概念上讲，微服务完全符合 Serverless 功能结构，微服务可以轻松实现不同服务的部署和运行时隔离。在存储方面，像 DynamoDB 这样的服务可以让每个微服务拥有独立的数据库，并独立地进行扩展。 在我们深入探讨细节之前，先别急着“站队”，不妨先基于你团队的实际情况，真实的去思考是否适合使用微服务，千万不要因为 "这是趋势 "而去选择它。 微服务在 Serverless 环境下的优势 可选择的可扩展性和并发性 Serverless 让管理并发性和可扩展性变得容易。在微服务架构中，我们最大限度地利用了这一点。每一个微服务都可以根据自己的需求对并发性/可扩展性进行设置

简介： 马上就要 2021 年了，Serverless 是否终将取代微服务？从微服务到 Serverless 需要经过怎样的路径？本文将对 Serverless 与微服务在优势劣势上进行深度对比。 来源 | Serverless 公众号 编译 | OrangeJ 作者 | Mariliis Retter “Serverless 能取代微服务吗？” 这是知乎上 Serverless 分类的高热话题。 有人说微服务与 Serverless 是相背离的，虽然我们可以基于 Serverless 后端来构建微服务，但在微服务和 Serverless 之间并不存在直接的路径。也有人说，因为 Serverless 内含的 Function 可以视为更小的、原子化的服务，天然地契合微服务的一些理念，所以 Serverless 与微服务是天作之合。马上就要 2021 年了，Serverless 是否终将取代微服务？从微服务到 Serverless 需要经过怎样的路径？本文将对 Serverless 与微服务在优势劣势上进行深度对比。 从概念上讲，微服务完全符合 Serverless 功能结构，微服务可以轻松实现不同服务的部署和运行时隔离。在存储方面，像 DynamoDB 这样的服务可以让每个微服务拥有独立的数据库，并独立地进行扩展。 在我们深入探讨细节之前，先别急着“站队”

作者：昱坤 在公有云方案日益火爆的今天，公有云应用越来越广泛。随之而来的，公有云也遇到了一些挑战：  传统数据中心产品不一定支持云环境  传统的产品不一定支持云弹性的部署以及模块化的部署  云架构的部署思路与传统物理环境部署环境完全不同  传统的安全防护很难在多云环境提供统一安全解决方案  遇到最多的问题就是：我们云环境一定要和物理数据中心架构一样 而在企业进行公有云迁移时对于安全和自动化的要求，AWS上有了新的安全自动部署方案： 在该方案中，可以将防火墙部署在Transit VPC中，以实现VPC与VPC间/VPC与Internet间等的安全加固需求。此文仅介绍Fortinet AWS 的安全解决方案。 Fortinet云部署实例要求 如果要在AWS上部署FortiGate-VM，那么实例需要满足以下要求： Fortinet常见云部署模式 针对AWS云上部署，Fortinet提供两种常见的部署方案： NGFW 和ELB部署形式  两个AZ的FW与WAF工作在AA模式  入向流量通过ELB负载分摊  FW开启NGFW威胁检测功能  FW将流量映射至内部ELB FQDN NGFW以及WAF 和ELB部署形式  FW与WAF完全集成将HTTP转至WAF  WAF对HTTP流量进行深度检测  WAF将HTTP流量映射至内部ELB 在该部署模式下

想要成为一名解决方案架构师，你要过的第一关就是通过相关的考试以获得专业认证，这能证明你已经掌握了一些知识，并且能够设计复杂的系统。 成为解决方案架构师并不是一件容易的事情，首先你需要成为一名优秀的工程师。这意味着你已经非常了解算法，并且知道如何有效地应用它们，优秀的开发人员还得具有设计复杂体系结构系统的经验。 目前最受欢迎的认证是AWS解决方案架构师、Azure解决方案架构师和谷歌云平台架构师。我将指导你完成准备AWS解决方案架构师考试的必要基础知识，这些基础知识也适用于其他认证考试。 计算能力 这是所有云系统的基本支柱，无论云系统背后是真实的实体服务器还是虚拟的环境。对我们来说，重要的是一个专门运行应用程序的地方，以及能够恰当地处理工作量的能力。因此，理解配置不同类型的计算系统的概念至关重要。 如果应用程序消耗大量计算资源，那么系统应具有足够的中央处理器(CPU)和随机存取存储器(RAM);如果应用程序执行许多I/O操作，那么系统需要集中精力进行配置。 图源：unsplash 了解应用程序的必要性有助于定义系统需求。例如，在亚马逊上，弹性云计算(EC2)是一项可以提供计算能力的服务，它具有各种类型的实例来满足不同的需求，做出正确的选择还可以节约成本。 自动伸缩组(ASG)是AWS中的服务。一旦用户基础增加，可伸缩性问题可能就会出现，这就是自动伸缩的概念。如果没有足够的资源

作者介绍 Nick， 携程软件技术专家，关注分布式数据存储以及操作系统内核。 在 《携程 Redis 跨 IDC 多向同步实践》 一文曾和大家分享过携程在 Redis 双向同步方面的心得，简单介绍了实现一个 Redis 双向同步系统中可能面临的问题，以及其中一种问题（分布式一致性）的部分处理方案 -- CRDT（Conflict-free ReplicatedData Types）。 本文将进一步阐述在具体设计和落地过程中的一些细节，希望对大家能够有所帮助。包括： <ul class="list-paddingleft-2" style="margin: 0px; padding-right: 0px; padding-left: 30px; box-sizing: border-box; > Cycle Break -- 如何打破盗梦空间的无限循环； Last Write Wins & Vector Clock -- 冲突的解决既简单又复杂； Tomstone -- 忆往昔才能看今朝； GC -- CRDT 取经之路的通天河； Expire -- 一致 or 不一致， 这是个问题。 相信通过对这些问题的描述和解答， 大家对于如何实现一个双向同步的 Redis 会有一幅清晰的构图。 一、Cycle Break —— 如何打破盗梦空间的无限循环 1、复制回环 以下图为例： 假设 A

如今，企业上云离不开数据库上云。然而，云上有很多数据库类型，企业该如何选择？将数据库迁移到云端，该有哪些步骤呢？不同的业务场景下，企业该如何选择？本文将介绍 AWS 各种常用数据库特性，以及如何满足客户不同业务需求，并列举数据库迁移案例为大家演示如何轻松便捷的把数据库迁移上云。 一、AWS 数据库概览 在这个互联网极其发达的时代，我们每个人会接收以及生产各式各样的信息，数据的重要性已经***到每个角落，成为每个行业发展和变革的必要元素。我们日常使用的手机应用，比如微信、支付宝、微博等，里面的数据都是需要数据库来进行存储，不同的应用会使用不同类别的数据库，甚至同一个应用可能同时使用多种数据库。 应用离开了数据库就像鱼儿离开了水，由此可见数据库在当今互联网的重要性。我们甚至可以说当今世界最宝贵的资源不再是石油，而是数据。随着业务的快速发展，全球化业务新兴需求增加，本地传统数据库已经无法为快速发展的业务提供支持，我们需要探索一种新的方式，把本地数据库迁移到云中，利用云中数据库的优势来解决本地数据库中遇到的瓶颈问题。 我对各家云厂商数据库种类做了一个比较，发现 AWS 为用户提供的数据库种类最为丰富，几乎把所有数据库相关的应用场景都捕捉到了。下面通过一个列表，来浏览一下 AWS 的数据库种类，其中关系型数据库最为丰富，也是目前应用使用最多的数据库。 以上这些数据库由 AWS 完全托管

没有 web 接口开发经验，只会简单写一写功能函数，有没有办法写一个收集客户端数据的接口呢？本文将一步步带你如何在没有接口开发经验的情况下轻松的使用 AWS 服务器服务构建自己定制化的 API 接口。 一、前期准备 1.1、业务需求 假设 T 公司有一个全球性的网站，每个国家站点都有一个下载页面。公司想要去监测全球用户的下载情况，需要对下载按钮进行埋点，那我们就需要有一个接口可以监测到用户的下载情况，需要记录的数据有如下： country：用户来自哪个国家 create_time：下载时间 ip：用户的 IP referer：从哪个页面下载的 site：国家站点代码 我们不可能针对每个站点都做一个链接作为借口，最好的方式就是创建一个链接，通过传递不同的参数来埋到不同的下载按钮，链接类似下面结构： https://down.wzlinux.com?type=CN https://down.wzlinux.com?type=US https://down.wzlinux.com?type=IN 1.2、解决方案 看到这个需求，一个专业的开发人员可能很快可以解决，需要较高的开发技能，还需要运维购买服务器，部署等，相对来说比较麻烦，并且管理起来相对复杂。本文所展示的就是你只会简单的功能函数开发即可完成这个需求的开发部署，而且全部使用 AWS 的无服务器组件，用户不需要再关系底层硬件

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 有人说，程序员总是对好的东西如数家珍，对不好的东西置若罔闻。2015 年，当微服务炒作开始飞起，每个人都在议论它的好处： 弹性； 伸缩性； 易于部署； 清晰的边界。 我们公司也从单体转向了微服务，但最后在二者之间找到了一个平衡点。微服务的一些好处是切实存在的，但它的一些缺点和潜在风险也不可忽视。 从单体到微服务 我于 2017 年加入公司，当时我们的团队大约有 20 名工程师，我们的应用程序是一个部署在 ECS 上的 Django 单体。 在过去两年里，我们开发了很多新服务，以下是一个不完整的清单： 票据服务：管理客户票据； 收费服务：管理 Stripe 的收费和支付； 定价服务：管理服务定价； 匹配服务：为企业经理和供应商之间牵线搭桥； 消息服务：管理聊天功能； 通知服务：管理推送通知、应用内通知和邮件； 审核服务：供应商审核客户； Netsuite 同步服务：将数据同步到 Netsuite； Salesforce 同步服务：将数据同步到 Salesforce； Stripe 同步服务：Stripe 和我们的系统之间的一个传输层； RDS 监控服务：确保我们的 Postgres 数据库正确备份； Datadog 监控服务：监控 Datadog 代理运行正常； GitHub