云架构的思考3--云上开发

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理论，也就是最终一致性，而最终一致性是云上解决方案中最常见的。无状态服务就是实现最终一致性的基础之一，因为它具有幂等性。
• 云上Serverless：Serverless这个词也出现了很久，各大云厂商都有相关的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 总结

开发是一门细腻活，云上开发可以理解是一种基于不同环境不同机制下的新的开发方式，但是又不脱离原先的开发，只不过是在原先的开发基础上增加了其适配云上特点的特殊性，因此这方面还需要多加积累，这里只是阐述本人在云上开发的一些常见问题的经验。