手机版网站设计案例,湖北住房和城乡建设厅网站,wordpress dplayer使用,网站后台登陆路径目录 1 DevOps--简单灵活性高2 服务化#xff08;微服务#xff09;--弹性#xff08;可扩展#xff09;、按需自主服务3 无状态#xff08;Serverless#xff09;--弹性#xff08;可扩展#xff09;4 日志--安全5 配置中心--安全6 设计模式6.1 使用“适配器模式”调用… 目录 1 DevOps--简单灵活性高2 服务化微服务--弹性可扩展、按需自主服务3 无状态Serverless--弹性可扩展4 日志--安全5 配置中心--安全6 设计模式6.1 使用“适配器模式”调用SDK/API6.2 使用“断路器模式”增强容错性6.3 使用“补偿机制”实现最终一致性6.4 使用“事件源模式”化繁为简6.5 使用“管道模式”提高扩展性6.6 使用“Sidecar模式” 7 总结 前面2章我们了解了云计算的特点、服务模式、部署模式以及云上架构设计的通用步骤这一章我们来聊一下更加细的一方面就是云上开发。有人说云上开发跟我们平时开发有什么不一样的不就是写写代码莫非还有语言和设计模式不一样首先在语言上和设计模式上没有什么不一样但是上云的开发与我们平时开发还真有一些不一样这里并没有统一规则只是本人在开发过程中的一些经验总结。 首先我们回顾一下之前第一章所讲的云的特点弹性可扩展性、按需自主服务、经济性、简单灵活性高、安全等5个方面。那么架构都要匹配和利用好这些特点那么在开发中也需要很好利用这些特点来实现你的开发这样既能让你的开发效率提高也能让你的开发能够匹配上云的设计。 1 DevOps–简单灵活性高
DevOps这个词已经出现很久了并且在很多公司已经很好落地真的实现快速并且可靠的交付。DevOps不仅是一种文化解决从设计、开发、测试、上线、维护等各个环节的沟通问题同样也需要一套工具支撑。对于DevOps的相关概念作用等内容在网上已经有很多这里不在累述这里主要讲的是DevOps与云上开发的关系或者说云上开发为什么需要DevOps。归纳为以下几点
自动化基础设施云基础设施都是面向代码化IaC为的就是提供高可靠性屏蔽底层异构性那么这个和DevOps的初衷之一高可靠性就很符合因此2者一拍即合因此你会看到很多云厂商上面已经有各种成熟的部署环境你只需要选择你合适的基本不需要你做任何修改并且还经常更新和维护。快速部署DevOps的初衷之一就是快速交付而DevOps也有快速交付的目的因此你在云厂商上面都能见到一整套成熟的DevOps工具你无需做任何安装和部署只需要几分钟就能创建出一套DevOps从设计、开发、测试、上线和维护的流程。持续集成持续交付CI/CD这个词对于任何开发人员来说都不陌生强调的是能够迅速并且持续测试并高质量交付。要做到这一点需要的是自动化测试、自动化部署同时也能够敏捷试错。那么这对于云来说也是天然属性之一还记得在第二章中讲过有人就是利用云来作为其测试环境其实就是利用云的快速且多类不同环境的特点。
我不知道一开始2者是谁推动了谁那是我现在我觉得2者是相互相成的。因此我们在云上开发优先会考虑使用DevOps的开发机制这样既能利用到云的特点也能享受其带来的效率。
2 服务化微服务–弹性可扩展、按需自主服务
你一定听过RESTful但你不要觉得它是一个很深很复杂的东西简单理解就是提供规范化的API。提供规范化API其实就是屏蔽你内部系统的所有细节对外提供统一的语言这样做的好处显而易见就是能让不同技术栈实现的东西相互之间调用和访问说的简单一点就是服务化。服务化对于云上开发的重要性有以下2个原因
云本身就是服务化如你所见所有云产品都会提供标准API供用户使用其实就让客户能够轻松的兼容不同技术栈的内容只需要关注服务的功能而你自身的代码也需要做到如此就能更好的兼容云这样别人在使用你的服务也如同使用云上服务一样。服务化能解耦我们知道解耦是一个非常基本的设计要求力求的就是一个简单并且可扩展性。云特点之一就是弹性只有当你解耦了那么才能利用弹性伸缩。因此服务化设计能让你开发的内容很好利用云上弹性特点。
那么服务化选择SOAP、RESTful或者GraphQL这个仁者见仁智者见智没有说一定的统一规范但是我个人觉得RESTful是一个比较好的方案理由如下
它是一种比较简单和易理解的标准它已经被广泛结束的标准它的约束条件很符合云上的容错设计
无论你选择哪一种解决方案但是是你开发的产品、系统、功能变成服务化是一个云上开发的基本准则之一。
3 无状态Serverless–弹性可扩展
无状态其实在多线程、多进程、微服务或者分布式系统中都会提及到并非什么新的内容。简单来说无状态就是只关注输入内容不存在程序状态也就是无论什么时候一样的输入内容会得出一样的输出结果。那么这个与云上开发有什么关系
弹性云一大特点之一就是弹性弹性就意味着你的程序可以伸缩那么不能因为在A容器/机器上面执行与在B容器/机器上面执行会得出不同的内容。只有无状态程序才能很好的利用云的弹性。最终一致性在云上这种解耦的服务化模式下要实现ACID的事务强一致性是需要付出比较大的代价那么在设计过程中尽量遵循BASE理论也就是最终一致性而最终一致性是云上解决方案中最常见的。无状态服务就是实现最终一致性的基础之一因为它具有幂等性。云上ServerlessServerless这个词也出现了很久各大云厂商都有相关的Serverless产品比如AWS的Lambda、阿里云的函数计算等其主要目的就是你只需要实现关键业务的部分其它的交由基础设施来实现。那么Serverless的要求之一也就是无状态。
因此总的来说无状态的代码设计对于云上开发尤为重要开发设计无状态程序可以重复利用云的弹性也保持迁移Serverless的可能性。
4 日志–安全
日志在第二章中已经详细说明了为什么要做一个统一集中的日志管理这里要强调的是开发过程中不能像我们以前那样在本地写日志那么简单有更多的方案选择因为如果写入本地在云上有可能部署的是一个伸缩容器一旦容器回收日志则会被删除掉因此需要参照第二章2.7.1中的方式同时日志格式也是需要参照架构统一规范。
5 配置中心–安全
从部署上考虑无论开发环境和生产环境都要尽量保持一致那么配置化如数据库、第三方api等配置都会影响部署代码不一致所以最好通过环境变量来读取配置中心的配置。从安全性考虑将一些资源地址密钥放在部署包中是非常不安全的。在云上开发都会提供安全性的配置管理中心。因此使用一个云上配置中心是非常有必要的。
6 设计模式
是的开头说了云上的开发设计模式跟我们平时的设计模式没有什么不一样那么这里要讲的是利用平常的设计模式在云上开发中某些关键点的使用。
6.1 使用“适配器模式”调用SDK/API
我们知道适配器设计模式就是将某个类的接口转换成客户端期望的另一个接口表示那么在云开发中我们经常使用到云的SDK或者API但是不同云厂商之间的SDK/API的规范有些不一致对于我们的开发来说如果程序需要运行于不同的云厂商那么就需要每每适配一个SDK/API因此在调用云厂商的SDK/API时可以使用适配器模式这样对于原先代码不需要做任何修改只需要增加不同适配器以达到适配不同云厂商的效果
6.2 使用“断路器模式”增强容错性
在云上的服务都是有一定的不可用性或者说服务不可用是经常发生的事情这个也是微服务的特点。那么为了保证我们服务不受其不可用影响或者降低其不可用对我们程序的影响使用断路器模式在下游服务不可用时可以做备用方案减少或者屏蔽其服务不可用带来的损失同时还具备重试功能。
6.3 使用“补偿机制”实现最终一致性
最终一致性是以一种比较低的代价实现一致性的方式而云上开发使用BASE理论使用最终一致性是一种常见方式。最终一致性需要一个兜底的方案那就是补偿机制因此在开发中设计补偿机制是云上开发的一种必须考虑的设计模式。
6.4 使用“事件源模式”化繁为简
事件源模式指的是系统中发生的事件会触发相应的事件处理器或监听器从而实现特定的业务逻辑或功能。该设计模式最大好处就是解耦并且能够化繁为简。在云上开发中经常会被使用特别是Serverless开发基本上这是基本实现模式。
6.5 使用“管道模式”提高扩展性
管道模式是将执行复杂处理的任务分解为一系列可重用的离散元素。通过允许独立地部署和扩展执行处理的任务元素该模式可以提高性能、可伸缩性和可重用性。这样的模式在云上设计特别是复杂任务需要利用云的弹性以提高性能最适合不过我们可以考虑比如数据计算、机器学习等方面使用。
6.6 使用“Sidecar模式”
Sidecar模式在ServiceMesh中被用得淋漓尽致原因就是它能够将与业务无关却是业务需要的通用功能剥离出来以边车的模式同业务一起运行。这样能解决与业务解耦同时它本身的升级与业务模块升级也能分开因此在云上开发也可以考虑使用这样的模式。
这里只是简单列举一些常见的模式当然还存在很多其它云上设计模式这些需要大家在上云过程中慢慢积累。
7 总结
开发是一门细腻活云上开发可以理解是一种基于不同环境不同机制下的新的开发方式但是又不脱离原先的开发只不过是在原先的开发基础上增加了其适配云上特点的特殊性因此这方面还需要多加积累这里只是阐述本人在云上开发的一些常见问题的经验。
