东莞市研发网站建设公司,wordpress换php7出错,简历制作在线,别人盗用我的网站备案号怎么办改变思维的角度#xff1a;故障无处不在 当微服务规模化后#xff0c;故障是无可避免的#xff0c;以往我们总是想尽力避免故障的发生#xff0c;而当故障实际发生时#xff0c;我们往往束手无策。我们花了很多时间在流程设计和应用设计的层面上来阻止故障的发生#xff…改变思维的角度故障无处不在 当微服务规模化后故障是无可避免的以往我们总是想尽力避免故障的发生而当故障实际发生时我们往往束手无策。我们花了很多时间在流程设计和应用设计的层面上来阻止故障的发生但实际上很少花费时间思考如何第一时间从故障中恢复过来。 一些公司喜欢组织活动活动当天系统会被关掉以模拟故障发生然后不同团队演练如何应对这种情况。这些项目中最著名的是混乱猴子Chaos Monkey在一天的特定时间随机停掉服务器这促使开发人员在构建系统时不得不为它做好准备。猴子军队可以在系统中注入网络延迟也可以随机关闭整个可用区这可以让你的系统得到终极验证。SimianArmy就是这样的一个项目。 通过让软件拥抱和引发故障并构建系统来应对。 了解什么指标是我们必须关注的 企业Wiki一个月发生故障两天我们认为是可以接受的电商网站一天停一个小时也是不可接受的。我们需要正确地理解这些需求以便采取合适的技术。 我们建议有一些默认的指标必须予以关注。 1.响应时间/延迟 鉴于网络的性质你经常会遇到异常值所以将监控的响应目标设置成一个百分比是合理的。 举例我期望这个网站当每秒处理200个并发连接时90%的响应时间在2秒以内。 2.可用性 评价可用性我们可以从历史报告来分析以跟我们的期望值相对比。 3.数据持久性 用户的登录会话只需要保持一年金融交易记录则需要保存很多年。 一.从体验上来解决功能降级 当购物车功能不可用时你可以隐藏掉这个图标并提示“马上”或者变成一个可下单的电话号码。 对于每个使用多个微服务的面向用户的界面或每个依赖多个下游合作者的微服务来说你都需要问自己“如果这个微服务宕掉会发生什么”然后你就知道该如何做了。 二.从请求/响应上来解决 1.超时机制 给所有的跨进程调用设置超时当发生超时时记录到日志中并相应地调他们。 2.断路器 当对下游的请求发生一定数量的失败后断路器会打开接下来所有的请求在断路器打开的情况下会快速地失败一段时间后客户端发送一些请求查看下游服务是否已经恢复如果它得到了正常的响应将重置断路器。
使用断路器我们可以在请求失败后把这些请求存起来然后稍后重试它们也可以直接使用功能降级。Hystrix就是一个基于JVM的开源断路器。 3.舱壁
这是一种把自己从故障中隔离开的方式如果我们使用下游多个服务而其中一个服务占用了过多的连接池由于是共用连接池这势必会对其他的服务调用造成影响舱壁的处理办法即是为每个下游服务建立一个单独的连接池我们当然也可以跟断路器联合起来使用。 在很多方面舱壁是三个模式中最重要的超时和断路器能够帮助你在资源受限时释放它们但舱壁可以在第一时间确保它们不成为限制它可以拒绝请求以避免资源达到饱和。 三.从服务依赖性上解决隔离 一个服务依赖于另一个服务另一个服务的健康将能影响其正常工作的能力如果我们使用的集成技术允许下游服务器离线上游服务便不太可能受到计划内或计划外宕机的影响。 Jekins的master/slave即是这样的解决思路。 四.从处理结果上解决幂等 对幂等操作而言多次执行所产生的影响均与一次执行的同如果操作是幂等的我们可以对其重复多闪调用而不必担任会有不利影响。当我们不确定否被执行想要重新处理消息从而从错误中恢复时幂等会非常有用。 五.从应用上解决扩展应用 更强大的主机、一台主机一个微服务、关键业务弹性部署、多云服务数据商备份、异地灾备、负载均衡、重构系统、作业队列。 六.从数据库上解决扩展数据库 方法1主从复制 当主数据库出现故障可以马上启动备份数据库并提升至主数据库。 方法2读写分离——扩展读操作 读操作使用的数据库和写操作使用的数据库分开但这会造成数据暂时不一致的情况。 方法3读写分离——扩展写操作 可以使用分片的方式来扩展写操作当你有一块数据要写入时对数据的关键字应用一个哈希函数并基于这个函数的结果将数据发送到哪个分片。 但分片扩展会导致在查询上复杂起来如果要查询所有年满18岁的顾客那么要查询所有分片然后在内存中拼起来或者有一个替代的读数据训包含所有的数据集。 分片扩展的另一个问题是如果想添加新的数据库节点我们需要大量的宕机时间然后重新分配数据 方法4CQRS——命令查询职责分离 在传统的系统中数据的修改和查询使用的是同一个系统使用CQRS后系统的一部分负责获取修改状态的请求命令并处理它而另一部分则负责处理查询。 七.从缓存上解决缓存 1.客户端、代理服务器和服务器端缓存 使用客户端缓存客户端会缓存存储的结果由客户端决定何时获取最新副本。我们可以通过服务来告诉客户端应该更新缓存了。 代理服务器缓存将一个代理服务放在客户端和服务端之间反向代码或CDN就是这样的例子。 服务器缓存由服务器端处理缓存Redis、Memcache、内存缓存就是这样的系统。 2.HTTP缓存 标准的静态网站像CSS或图片很适合用HTTP中的cache-control和Expires指令另外还可以使用HTTP的ETag来标示资源是否已改变如果我更新了客户记录 虽然访问资源的URI相同但值已经不同所以我会改变ETag。 3.使用写缓存 你可以先写入本地缓存并在之后的某个时刻将缓存中的数据写入下游当你有爆发式的写操作时或同样的数据可能被写入多次时或下游服务不可用时这种方式都是很有用的。 4.为弹性使用缓存 我们可以缓存一个时间点的数据在故障发生时提供这个时间点的数据虽然可能不完全正确最起码可以用。 5.隐藏源服务 有可能我们系统的80%请求都是通过缓存那么缓存一旦失败请求都将进入源服务源服务从来没有处理过这么多请求这将是灾难性的我们可以阻塞请求并在后台异步重建缓存。 6.避免过多地使用缓存 缓存越多就越难评估数据的新鲜程度。 7.防止缓存中毒 你可能在系统中将HTTP缓存头的过期时间设置为Expires:Never这样除非用户手工清除他们也许CDN也会缓存这些内容否则永远不会失效这时我们唯一的选择就是改变这些网页的URL以便能够重新获取它们。 使用自动伸缩 现在的云服务提供商允许你制定自动伸缩服务的策略通过响应式伸缩或者预测式伸缩帮助你在高峰有可能是秒杀有可能是突发式新闻也有可能是因为周末到来的时候提供服务。 CAP理论 Eric Brewer的CAP理论告诉我们一致性Consistency、可用性Availability和分区容忍性Partition Tolerance最多只能同时保证三个中的两个。 牺牲一致性 我们只需要数据保持最终一致就可以了因为我们需要分区来保证数据的安全性同时保证系统的可用性。博客园我更新博客时每个月份的博客统计数不会马上更新就是这样。 牺牲可用性 像12306这样的网站每天晚上维护就是牺牲了可用性。 牺牲容忍性 既然是分布式系统这种情况是肯定不存在的。 服务发现、注册与编排 方法1DNS DNS让我们将一个名称与一个或多个机器的IP地址相关联例如我们可决定在accounts.hello.com上发现账户服务这个域名会关联到运行该服务的主机的IP上或负载均衡器上。 DNS的好处在于它是但不好的地方在于更新它不是那么容易而且对于一个新的节点DNS不能“发现”这个节点。 方法2Zookeeper 它支持配置管理、服务间的数据同步、leader选举、消息队列和命名服务。它的核心是提供了一个用于存储信息的分层命名空间客户端可以在此层次结构中插入新的节点更改或查询它们。 方法3Consul 它也支持配置管理和服务发现但它比Zookeeper更进一步为这些关键使用场景提供了更多支持如它为服务发现提供了一个HTTP接口另外它提供了现成的DNS服务器。 Consul还内置了一些功能如对节点执行健康检查的能力。 Consul从注册服务、查询键/值存储到插入健康检查都使用的是RESTful HTTP接口这使集成不同技术栈变得简单。 方法4Eureka 它提供了基本的负载均衡功能它可以支持服务实例的基本轮询调度查找它提供了一个基于REST的接口因此你可以编写自己的客户端。 文档服务 微服务非常多暴露的接口更多我们希望知道关于这些接口的说明理想情况下我们会确保文档总是和最新微服务的API文档同步并当大家需要知道服务在哪里能够很容易地看到这个文档。 1.Swagger Swagger让你描述API产生一个很友好的Web用户界面使你可以查看文档并通过Web浏览器与API交互还可以直接执行请求。 2.HAL和HAL浏览器 它是用媒体来生成我们的文档。 参考 《微服务设计》Sam Newman 著 / 崔力强 张骏 译
相关文章
微服务的概念——《微服务设计》读书笔记微服务架构师的职责——《微服务设计读书笔记》建模:确定服务的边界——《微服务设计》读书笔记微服务集成——《微服务设计》读书笔记服务的协作服务间的消息传递——《微服务设计》读书笔记拆分:分解单块系统——《微服务设计》读书笔记部署:持续集成CI与持续交付CD——《微服务设计》读书笔记测试——《微服务设计》读书笔记监控——《微服务设计》读书笔记安全——《微服务设计》读书笔记康威定律和系统设计——《微服务设计》读书笔记
原文地址http://www.cnblogs.com/gudi/p/6686277.html .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
