企业做网站有哪些好处,wordpress.or,网站开发那个好,wordpress怎么进主页本文要点
袜子商店应用始于一个简单的演示应用#xff0c;之后发现它十分有用#xff0c;最终演化成一个完全容器化的、云原生参照应用。该应用混合使用了Go、Java、Spring以及Node.js。它拥有完整的持续集成和发布管道#xff0c;最终会发布到AWS上Kubernetes集群的准生产…本文要点
袜子商店应用始于一个简单的演示应用之后发现它十分有用最终演化成一个完全容器化的、云原生参照应用。该应用混合使用了Go、Java、Spring以及Node.js。它拥有完整的持续集成和发布管道最终会发布到AWS上Kubernetes集群的准生产环境中。其中的API使用了Open API的规范。并且使用了一个名为Dredd的工具用其获得swagger规范并且对在容器化的服务上的API进行验证。袜子商店可以使用独立Docker、Docker Swarm、Kubernetes、Mesos/Marathon或DC/OS、Hashicorp的Nomad以及AWS ECS进行部署。在合并两个服务成为单个服务时会遇到远超预期的麻烦。因此建议在完全理清服务之前尽量推迟对服务的拆分。
微服务、容器和编排框架是一个不断变化的领域。每周都有新的工具、服务或产品出现同时伴随着新的概念、技术和流行语。为了达到在构建应用时“云端优先”的新兴思想就诞生了云原生Cloud Native一词。然而试图确定云原生究竟意味着什么将是徒劳的因为它所试图定义的领域正不断变化着。我们看到最近的一个动向就是云原生计算基金会Cloud Native Computing Foundation的成立。它归属于Linux基金会是一个专注于常用技术和开源软件的非营利性组织。
这看上去正朝着正确的方向发展但还是没有能帮我们定义云原生应用到底是什么。我们可以说出一些技术如容器、编排框架和一些最佳实践如短小、可扩展、灵活但拥有一个具体的参照往往会更有帮助。这正是我们所一直在构建的。 这就是袜子商店应用一个真实、完全容器化、采用微服务架构的云原生应用。
该项目一开始是作为DockerCon的一个小型演示应用而诞生的用于展示由Weave Works开发的一些新服务。作为一家致力于为微服务和基于容器的应用构建产品和工具的公司他们需要一个真实的应用来演示他们的服务。在两周内我们构建了一个大量使用微服务的应用其中投入了各种技术、编程语言和数据存储。
相关厂商内容微信Android模块化架构重构实践蘑菇街分布式消息中间件Corgi的架构演进Serverless架构一条SQL到一个服务有多远对抗复杂性架构设计中可借鉴复用这些手段阿里风控场景的模型平台架构设计
相关赞助商 ArchSummit深圳20177月7-8日深圳·华侨城洲际酒店精彩内容抢先看
初次运行之后我们看到了持续维护该项目的好处。它既可以作为容器和微服务集中工具的测试平台同时可以作为云原生系统的参照应用这会非常有用。在接下来的几个月中我们致力于将此演示应用转换为可以部署到生产的应用。我们对每个服务进行了彻底改进、按需替换数据存储、合并高耦合的服务、并添加日志和监控等标准功能。我们还建立了完整的持续集成和交付管道最终会发布到AWS上Kubernetes集群的准生产环境中。
微服务
云原生应用必须足够灵活。我们需要快速而独立地部署从而让我们在正确的时间做出正确的决定和变化。这能使组织架构变得敏捷。组织内部应该预期并鼓励变化而不是极力规避变化。云原生应用注重服务的独立性。系统的每一部分都不应该相互依赖以避免造成级联故障。最后云原生应用应该是技术无关的。为系统的一个部分选择编程语言或者为特定数据集选型关系型数据库不应对系统的其他部分造成影响。
显然这些不是我们可以通过独立应用架构来实现的。虽然不是所有情况下都必要但是云原生应用还是应该构建在微服务之上。在袜子商店应用中我们积极地在应用中使用“微服务”的理念。 这给了我们诸多好处我们能够利用多种持久化技术即在不同的服务使用不同的数据存储。我们也可以为每个服务自由地选择语言。但真正的好处在于开发的速度。由于这是一个开源社区项目短期内有很多开发人员参与。通过对服务进行适当的隔离大家可以很容易地融入社区并快速修复bug或在某一服务中添加功能而无需了解整个架构。
过分微服务化有观点认为一开始就使用微服务架构比转换现有的独立应用更加困难。其中一个原因是在一个全新的项目中服务之间的边界并不总那么清晰。如果你的服务沿着错误的边界进行划分最终服务间的交互就会过多而且这可能难以纠正。在我们袜子商店应用早期开发中就遇到这个问题。由于我们激进地对服务进行了划分我们创建了一个登录服务和一个顾客服务。在我们的后续开发中就发现它们之间的耦合度太高他们应该是一个服务而将它们合并成单个服务的过程又比预期设想的要更复杂。所以建议在完全理清服务之前尽量推迟对服务的拆分。
容器
微服务的广泛应用在很大程度上是由于一些新兴技术使我们可以更容易地将应用分割成小而独立的部分。具体地说就是容器技术。它为我们提供了轻量化的包装和工具。
除了越来越多地采用微服务外容器也是将应用从本地转移到云端的关键。无论是在容器中运行的应用本身还是应用运行所在的基础架构已经运行在容器上十多年的Google Cloud就是一个例子。容器是构成云的一砖一瓦也是云原生应用的重要组成部分。
在袜子商店应用中我们在各个部分都采用了容器。我们不光在docker容器上运行我们的服务更研究了如何在集成和部署管道中利用容器的优势。
一个例子就在我们的构建过程中。我们希望拥有一致、可重复的构建版本但是我们不希望在服务的镜像中包含不必要的工具使其变得臃肿。为了满足这个需求我们创建了单独的镜像来构建和运行我们的服务。构建的镜像包含必要的工具并在任何环境中提供了一致的可重复的生成文件。然后我们将构建的二进制文件或jar文件复制到实际运行服务的最小部署镜像中。示例
我们利用容器优势的另一个方面是在测试中这在微服务领域是有明显不同的。我们的服务规模相当合理因此可以轻松地测试内部功能。然而我们的服务有更多的外部依赖这为测试带来了一些棘手的问题。
我们测试的一个重点是我们的服务API。因为这些是我们服务间相互通讯的契约。我们使用Open API规范即Swagger记录了我们所有的API该API规范具有诸多的工具。我们使用了一个名为Dredd的工具它使用我们的Swagger规范并在我们容器化的服务上对API进行验证。当我们将其引入到持续集成管道中时我们能对所有服务的API进行持续地验证。所有这些都会在容器中运行这为我们的操作带来了可重复性并且这个过程与运行的平台无关。
我们创建了一个测试用的Docker镜像其中包含了我们的测试框架和Dredd工具。这个容器读入APISwagger规范并针对我们的真实服务进行API调用对API规范进行完整的验证。我们测试框架的生命周期是短暂的每个测试案例都会自己创建并删除独立的环境并且这个过程与运行环境无关。
编排
构建云原生应用的第三个支柱是编排orchestration。一旦我们创建、测试并部署完单个服务接下来的困难就是管理我们的各个容器以保持一个稳定而又灵活的运行环境。一旦你有多个容器手动编排就变得难以管理我们需要将其自动化。任何应用的主要部分包括运行服务的容器、服务器、存储和网络。从这组初始元素中我们就有了一个理想的状况运行应用、服务的发现、容错、资源的有效利用。理想情况下这一切都应该在没有任何手动干预的情况下完成。
幸运的是有许多工具和平台想要为我们管理这些。在袜子商店应用中我们决定在尽可能多的编排平台上部署我们的应用而不是选择某个特定的平台进行部署。毕竟作为一个参照应用它不应该与某个特定的平台绑定而作为一个真正的“云原生”应用它应该在任何编排平台上都可以正常工作。这种方式的另一个好处是可以让我们评估和比较不同的工具。在撰写本文时袜子商店应用已经可以部署在独立Docker、Docker Swarm、Kubernetes、Mesos/Marathon或DC/OS、Hashicorp的Nomad和AWS ECS上。可以查看对应的文档。
在大多数情况下应用在这些平台上“恰好可以正常工作”。我们只需要根据每个工具的语法调整配置文件就可以实现切换。由于我们所有的组件都是容器化的部署就变得直截了当。主要需要关注的是网络。我们使用了WeaveNet插件来满足我们的容器网络和DNS需求。在某些情况下这恰好可以满足需求但更多情况下这会与工具内置的现存DNS或网络组件产生冲突。容器网络接口将是未来的发展方向但是目前它仍处于早期阶段还不能与所有工具完全集成。
回顾云原生
云原生应用有三个主要支柱微服务、容器和动态编排。虽然其中经常涉及其他技术但构建云原生架构应用总会伴随着关注这三个方面。同时它们也是互补的技术。正如我们在袜子商店应用中看到的那样容器技术使构建、测试和部署微服务变得更加容易。添加了编排平台更使我们能够自信地大规模运行我们的应用。如果我们要手动管理每个服务的部署、重启、扩展和调度我们很快就会变得不堪重负这样就会使云原生应用所带来的好处不足以弥补维持应用运行所需的额外工作。
对于构建云原生应用其他的重要部分包括连续交付管道、全面监控和日志以及追踪所有这些都在袜子商店应用中有所使用。
袜子商店应用的下一步发展
既然现在该应用处于稳定状态并且我们已经进行了必要的自动化和测试接下来一个有趣的用例就是替换某些工具、语言、技术来看看这会带来什么样意外的问题以及这个过程是否能顺利进行。微服务架构常提及的优点之一我认为也是云原生应用的目标就是模块化。由于我们的应用的各种部件和基础设施之间的低耦合所以可以方便地使用等价的组件替换系统的任何部分。
一个有趣的例子就是我的一个同事使用.NET重新编写了我们的一个服务。目前在Linux上的.NET Core还相对粗糙除了由于这个因素所带来编写服务的一些挑战之外已经可以成功地将我们原来用Java编写的订单服务与.NET版本无缝切换。
作为一个稍稍极端的例子我想尝试着替换实际的容器运行时如使用rkt来替代当前的Docker。这将大大有助于展示我们在“云原生”上的发展并验证开放容器计划。
袜子商店应用的目标是成为一个云原生应用的参照也可用作相关技术、模式和工具的测试平台。它是一个完全由社区拥有和驱动的项目建议大家可以浏览一下代码、对应用进行测试、使用它来测试任何工具和新技术并通过PR贡献自己的代码。
关于作者
Ian Crosby是一位经验丰富的软件开发人员、拥护者和倡导者。他起步于军事防御系统的开发并一直以来致力于发挥自己的能力。目前他在阿姆斯特丹的Container Solutions担任高级工程师他协助各企业进入新的云原生领域同时与合作伙伴一起开发用于实现云端原生的工具。
原文地址http://www.infoq.com/cn/news/2017/06/CSharp-7.1-a .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
