云原生12要素
Yegor Bugayenko前几天写了一个有趣的博客，标题为“ SOLID是傻瓜的面向对象”。 好吧，如果SOLID是针对虚拟对象的OOP，我想知道他是否同意我的说法，即12要素应用程序的口号等同于针对云原生开发的虚拟对象？
我喜欢Bugayenko的文章，尽管看来他对此发表了很多评论。 但是我完全同意他的前提。 对我而言，告诉软件开发人员其应用程序应遵循SOLID原则，就像告诉马拉松运动员前进的最佳策略是使一条腿周期性地向前移动。 当然，这种说法是正确的，但是从本质上讲如此完全不言而喻的事情实际上算作建议吗？
重温SOLID原则
很快，SOLID原则如下：
·具有单一职责（S） ·面向对象（O） ·使用多态性或Liskov替代原理（L） ·利用接口（I） ·使用依赖性反转原理（D）抽象您的代码
所以我会看到的SOLID的五个原则的Bugayenko的批评，并提高他的云原生世界12因子应用的类似的批评。 （顺便说一句，如果您不熟悉所有最新的流行用语，Ken Owens在“将敏捷，DevOps，12因子应用程序和云原生计算结合在一起 ”一文中对云原生提供了一个很好的定义。）
回顾12要素应用
对于初学者来说，这些是云原生计算的12要素应用程序的十几个原则：
1. 代码库：在版本控制中跟踪一个代码库，许多部署 2. 依赖关系 ：明确声明并隔离依赖关系 3. 配置 ：将配置存储在环境中 4. 支持服务 ：将支持服务视为附加资源 5. 构建，发布，运行 ：严格分开的构建和运行阶段 6. 流程 ：将应用作为一个或多个无状态流程执行 7. 端口绑定 ：通过端口绑定导出服务 8. 并发性 ：通过流程模型进行横向扩展 9. 易用性：通过快速启动和正常关闭最大程度地增强鲁棒性 10. 开发/产品对等 ：使开发，登台和生产尽可能相似 11. 日志 ：将日志视为事件流 12. 管理流程 ：将管理/管理任务作为一次性流程运行
不言而喻的真理
认真地说，我们真的需要告诉软件开发人员，按照应用程序因素十（开发/产品平价）的指示，使生产，开发和登台环境尽可能相似吗？ 老实说，我永远不会记得在一个团队说“嘿，让DEV和PROD完全不同的项目”上工作。 就像，让我们在DEV中使用MongoDB，在生产中使用DB2.”
应用因素一，使用在修订控制中跟踪的一个代码库，这似乎既不是革命性的概念，也不是任何理性的云原生软件开发团队都会违反的原则。 也许如果他们使用MSD（ 受虐软件开发方法），他们可能会将代码分布在GIT，CVS，Clearcase和PVCS上，但是我看不到任何不是虐待狂的人。
因子九是完全可笑的。 有没有人真正坐下来写过一个用户故事或非功能性需求，描述他们希望它花很长时间来加载应用程序，并且他们希望在应用程序关闭时引起大麻烦？ 12个因素的应用程序的因素九，即通过快速启动和平稳关闭来最大化鲁棒性的一次性原则，意味着某些软件开发团队并不知道延长启动时间和关闭时挂起线程是一件坏事。
打破坚不可摧
老实说，有些原则我什至都不知道如何违反。 应用要素四表示，支持服务应视为附加资源。 我什至不知道如何编写一个不会将后勤服务视为附加资源的云原生应用程序。 这句话不是仅仅通过定义它是没有附加到您的云本机应用程序的后端资源这一事实就重言而论吗？
也许是因为过去二十年来我一直在Spring和Java EE平台上进行开发，所以其中一些观点似乎是多余的。 应用因子3指示云原生开发人员将配置详细信息存储在环境中，而不是将其作为一组常量或if-then-else语句添加到整个代码库中的各种不同类中。 老实说，我看不到有经验的专业人士添加Java代码，该代码将每个类括在条件语句中，条件语句根据当前托管该代码的环境来更改运行时行为。 此外，将配置存储在应用程序外部并抽象化依赖项一直是Spring和Java EE的基本原理。 这就是为什么存在资源引用和JNDI绑定的原因。
半生半熟的想法
如果不是Spring或Java EE强制实施这些最佳实践，那是应用程序服务器本身执行的。 应用因子11指出，日志应由执行环境捕获，并与云原生应用使用的所有其他日志流一起进行整理。 老实说，我不记得WebSphere没有这样做的时候。 也许IBM可以吞并云原生计算行业中的所有小厂商， 创建一个新的云原生应用服务器 ，并向业界展示如何完成日志记录？ 即使您只是使用System.out调用而不是使用诸如slf4j之类的适当日志记录框架，这种类型的功能也一直在应用程序服务器运行时中引入。
这个由12个要素组成的应用程序确实提供了一些思考的内容，其中大部分的智力上可食用的东西来自坚持认为使用进程（而不是线程）是扩展的最佳方法。 尽管我会断言这实际上只是一种语义论点，而不是实践中的论点。 传统的Java应用程序服务器确实运行有多个线程的一个进程，但Java微服务往往是单处理的，即使在微服务中，也存在多个利用线程的功能，因此这并不是一种非此即彼的方式 。 如果有六，八分之一的东西，将应用程序作为流程执行并使用流程模型进行扩展，则实际上可以断言整体是不好的，而将整体分解为较小的部分是好的。 我想我们大家都听说最近有人高呼这一口头禅。 是的，我们明白了。
Facebook股票和互联网模因
12要素应用程序信条的每个格言对我来说都像是贴在您遍布全国各地的办公室中的那些令人烦恼，鼓舞人心的海报上的东西。 我几乎可以形象地看到意大利跑车的海报，顶部是DISPOSABILITY，在底部是短语“通过快速启动和平稳关闭来最大化鲁棒性”。 我们确实生活在这样一个时代，为了被消费，每条消息都必须以模因或其他可以作为Facebook帖子共享或以140个字符的推文进行传递的方式传递。 也许这是新的开发人员，即社交媒体千禧一代，这是由12个要素组成的应用程序咒语所迎合的吗？
作为互联网模因的12要素应用程序
告诉我少吃多运动以减轻体重，这是毫无用处的建议。 告诉我按时缴税，避免利息和罚款也是无用的建议。 我的意思是，这些陈述是正确的，但是我不知道这一切，这使得陈述这些重言式陈述是浪费时间。 您可以将这些语句作为建议，但如果它们没有提供任何新内容，没有增值价值并且没有特别可操作的内容，则它们实际上不是建议。 我不禁感到，关于构建12因子应用程序的整个讨论都属于同一类。 我想知道叶戈尔·布加延科是否会同意我的看法？
这是Bugayenko的文章： 傻瓜的SOLID是面向对象的
您可以在Twitter上关注Yegor Bugayenko： @ yegor256 您也可以关注Cameron McKenzie： @cameronmcnz
对更多意见感兴趣？ 看看这些：
云原生12要素
扫一扫
708
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
