会员中心
搜索
登录
注册

解决方案

数字化转型通用方案行业方案安全方案大数据人工智能物联网行业展望自动控制其他

产品|技术

白皮书产品介绍技术介绍技术创新模型算法

政策|规范

政策规范行动计划

电子书

电子书课件

报告|论文

报告模板论文

基于 Kubernetes 的微服务项目设计与实现

随着互联网的发展，后端服务和容器编排技术的日益成熟，微服务成为了后端服务的首选，Kubernetes 也已经成为目前容器编排的事实标准, 微服务拥抱容器时代已经来临。笔者结合自己的经验，写了这篇微服务+ Kubernetes 入门宝典，希望能够抛砖引玉。能让大家了解 微服务和 Kubernetes 如何配合。上卷主要描述 微服务设计，项目实现，kubernetes 部署，微服务的部署 高可用和监控 这几个部分。下卷计划讨论服务化网格和数据持久化, 有状态服务，operator 这几部分。本文由我独立完成（ppmsn2005#gmail.com）如有任何错误，

  • 2021-06-28
  • 阅读218
  • 下载0
  • 53页
  • docx

架构与思维：设计容量，到底有多重要 ？

单位每年都会举行运动会，有一个2000m长跑的项目，大约每年报名人员为男选手40人，女选手20人，只有一条橡胶跑道。一次比赛10人齐跑，所以至少需要6场比赛。2000米的完成时间要求是20分钟，超过20分钟不计数，所以比赛耗时我们计算为20分钟，加上比赛前的动员组织，比赛后的清场，我们假定每场比赛耗时30分钟。现在我们预估下耗时：1、60人/10人每场 = 6场，至少需要举行6场2、总耗时 = 6场 * 0.5h = 3h所以每年把这个比赛安排在下午3点到6点，是最后一个比赛项目，晚上7点举行颁奖晚会。这个预估容量也算合理。但是今年比较特别，取消了4000米的长跑，所以2000米报名人员激增50人。时间还是下午3点到6点，这个就有问题了，最后为了保证晚会的正常进行，一半的人员的比赛时间推迟到另外一周的周末，搞得怨声四起，大骂举办的行政部门不讲武德。这个是我们单位真实的故事，这就是设计容量，当你的业务场景的容量发生了变化时候，没有预估到他的变化，以及变化可能产生的影响，没有按照这个影响及时的做调整（比如将比赛时间提前，拉长整个比赛的过程时间，或者增加比赛跑到，同时进行两场比赛），就会造成灾难。

  • 2021-06-28
  • 阅读193
  • 下载0
  • 4页
  • docx

如何让你的Nginx 提升10倍性能

提升Web应用的性能从未像今天这样刻不容缓。 在线经济活动的比例日益提高，就连发展中国家和地区的经济活动都已经有5%以上在线进行了（相关数据请参考本文后面的资源）。在这个超级链接、随时在线的现代世界，用户的期望也远非昔日可比。如果你的网站不能马上响应，你的应用不能立即运行，用户转身就会投奔你的竞争对手。亚马逊大约10年前的一项研究表明，页面加载时间减少1/10秒，能够使其营收增长1%。另一项近期的调查也显示，一多半受访站点所有者提到因为自己应用的性能不佳导致了收入减少或者用户流失。一个网站到底多快才行？页面加载每花1秒钟，就有大约4%的用户走掉。排名最靠前的电商站点的首次交互时间为1至3秒，这个区间的转换率最高。显而易见，Web应用性能的重要性与日俱增。提升性能其实不难，难的是怎么看到结果。本文给出能够提升大约10倍网站性能的10个建议供大家参考。如此全面地涵盖各种性能优化技术，这还是头一回，但这些建议可能需要NGINX的一点支持。除了性能，这些建议也会涉及提升安全性。

  • 2021-06-28
  • 阅读189
  • 下载0
  • 11页
  • docx

深入 Nginx 之核心架构篇

Nginx 作为业界知名的高性能服务器，被广泛的应用。它的高性能正是由于其优秀的架构设计，其架构主要包括这几点：模块化设计、事件驱动架构、请求的多阶段异步处理、管理进程与多工作进程设计、内存池的设计，以下内容依次进行说明。

  • 2021-06-28
  • 阅读156
  • 下载0
  • 10页
  • docx

微服务API设计的实践与思考总结

随着微服务的越来越流行，越来的越多的公司开始实行微服务架构，相对于单一应用架构，微服务将复杂性拆分并且打散到一个个粒度更加细分的应用中，极大了减少了开发中单个服务的复杂性，开发人员只需要面向专注单一业务场景编程，从技术开发角度，单一服务代码量上减少很多，从业务角度上，业务复杂性的降低降低了需求的沟通成本，然而，整体业务复杂性依然存在，当我们需要接入或者依赖其他服务时，通常作为接入方来说，我们不需要深入了解服务提供方的业务，此时API成为了开发人员间的沟通语言。良好的API设计，能极大的减少沟通成本，甚至有时候可以代替文档，尤其是对于基础性服务来说，服务的可扩展性有时候体现在API的可扩展性，我曾经参与过一个基础业务微服务的业务升级，由于旧版本的API划分不够清晰，部分API存在重复性，后面不得不对大部分API进行重构（替换为新版本的API），仅仅在服务消费方升级这个阶段就持续1-2个月之久，在这个过程中也不断对API设计中存在的一些问题以及应该遵循哪些原则进行了一些思考。

  • 2021-06-28
  • 阅读205
  • 下载0
  • 4页
  • docx

微服务之间的最佳调用方式

在微服务架构中，需要调用很多服务才能完成一项功能。服务之间如何互相调用就变成微服务架构中的一个关键问题。 服务调用有两种方式，一种是RPC方式，另一种是事件驱动（Event-driven）方式，也就是发消息方式。 消息方式是松耦合方式，比紧耦合的RPC方式要优越，但RPC方式如果用在适合的场景也有它的一席之地。 我们总在谈耦合，那么耦合到底意味着什么呢？

  • 2021-06-28
  • 阅读195
  • 下载0
  • 15页
  • docx

消息队列中：消息可靠性、重复消息、消息积压、利用消息实现分布式事务

可以利用消息队列的有序性来验证是否有消息丢失。在Producer端给每个发出的消息附加一个连续递增的序号，然后在Consumer端来检查这个序号的连续性。如果没有消息丢失，Consumer收到消息的序号必然是连续递增的，如果检测到序号不连续，那就是丢消息了。还可以通过缺失的序号来确定丢失的是哪条消息，方便进一步排查原因

  • 2021-06-28
  • 阅读167
  • 下载0
  • 12页
  • docx

微服务架构下的静态数据通用缓存机制

在分布式系统中，特别是最近很火的微服务架构下，有没有或者能不能总结出一个业务静态数据的通用缓存处理机制或方案，这篇文章将结合一些实际的研发经验，尝试理清其中存在的关键问题以及探寻通用的解决之道。

  • 2021-06-28
  • 阅读154
  • 下载0
  • 11页
  • docx