邢台提供网站建设公司哪家好,品牌商标,wordpress. 评论插件,wordpress 二次验证失败基于微服务的架构如今无处不在。 我们对Netflix和Amazon等当今的创新者如何利用它们在成功产生更多业务方面取得更大的成功了解到很多。 但是#xff0c;我们所有人都在使用Java EE应用程序服务器并编写经典系统吗#xff1f; 我们都做错了吗#xff1f; 我们如何使我们的技… 基于微服务的架构如今无处不在。 我们对Netflix和Amazon等当今的创新者如何利用它们在成功产生更多业务方面取得更大的成功了解到很多。 但是我们所有人都在使用Java EE应用程序服务器并编写经典系统吗 我们都做错了吗 我们如何使我们的技术设计适合未来 整体式 首先让我们研究一下那些经典系统。 或称为单片应用程序。 即使最近这些词有难闻的气味这也是我们构建软件很长时间的方式。 它基本上描述了以下事实我们构建单个应用程序来实现某些功能。 整体确实是指Java EE或最初设计的Java 2 Enterprise Edition的更好版本。 集中化的应用程序可以进行缩放和群集化但不必通过构建就可以使其具有弹性。 在大多数情况下他们在故障情况下都依赖于基础架构和操作。 传统上Java EE应用程序遵循一些核心模式并分为三个主要层表示业务和集成。 表示层打包在Web应用程序归档WAR中而业务和集成逻辑则放在单独的Java归档JAR中。 作为一个部署单元捆绑在一起创建了一个所谓的企业归档EAR。 围绕Java EE的技术和最佳实践一直足以构建设计良好的整体应用程序。 但是大多数企业级项目往往会失去对架构的关注。 这就是为什么有时精心设计的意大利面条球是可视化项目依赖关系和内部结构的最佳方法的原因。 当这种情况发生时我们很快就遇到了一些重大缺陷。 因为即使进行很小的更改所有东西都过于耦合和集成这需要大量的工作或有时需要大量的重构并且在将返工的零件投入生产之前还必须从头到尾仔细测试应用程序。 整个应用程序不仅仅是已编程的工件它还包括不可计数的部署描述符和服务器配置文件以及相关第三方环境的属性。 变更的高风险以及将新配置投入生产的复杂性导致发行量越来越少。 一个新版本每年发布一次或两次。 甚至团队结构也受到这些整体软件架构的严重影响。 数月的测试周期可能是最明显的证明。 但是除此之外寿命超过五年的项目往往会包含大量错误和功能数据库。 而且如果这还不够困难那么该测试就几乎没有资格-没有验收测试并且几乎没有任何书面业务要求或设计和可用性方面的可识别领域。 处理这类企业项目需要多个团队的共同努力并且需要很多人来监督整个项目。 从软件设计的角度来看最终的应用程序具有非常技术性的层次。 业务组件或域主要由现有数据库设计或过时的业务对象定义驱动。 我们的行业必须吸取这些教训我们不仅设法控制了这些企业整体还发明了新的范例和方法来更好地管理它们。 因此即使“独石”一词在当今被认为是设计不良的软件的代名词这些体系结构也有许多好处。 整体应用程序易于开发因为IDE和其他开发工具都是围绕开发单个应用程序而设计的。 它是一个归档文件可以与不同的团队共享并在其中封装所有功能。 另外围绕Java EE的行业标准使企业能够可靠地访问不仅构建而且还运行这些应用程序所需的资源。 软件供应商已经围绕Java EE建立了扎实的知识库并且采购通常不是大问题。 迄今为止与他们合作已有15年以上的时间该行业终于能够以或多或少的产品化和标准化方式来制造这些应用程序。 我们知道要使用哪些构建工具哪些流程可以在大型团队中扩展以及如何扩展这些应用程序。 自从出现Arquillian之类的工具以来甚至集成测试也变得更加容易。 为了像Java EE这样的成熟解决方案的便利我们仍在付出代价。 代码库可能会变得很大。 当应用程序在企业中停留更长的时间时它们将变得越来越复杂并且对于开发团队来说更难理解。 即使我们知道如何配置应用程序服务器每个项目中的一两个特殊设置仍然会引起操作上的头疼。 微服务 但是我们的行业并没有停滞不前。 几年前系统架构和设计的下一次发展才刚刚开始。 随着集中式集成组件的复杂性不断增加以及所连接应用程序的额外开销人们开始寻找更轻便更具弹性的产品。 最终整个理论从大型的重量级基础架构和设计转移了。 除此以外IT部门开始重新审视应用服务器以及冗长的协议和接口技术。 由于在基于SOA和ESB的项目中大多数服务实现都被证明是不切实际的因此技术设计又回到了更方便的工件和服务上。 微服务代替了智能路由和转换而是使用简单路由并将逻辑封装在端点本身中。 即使名称暗示了定义的大小也没有一个。 微服务是关于具有单一业务目的的。 对于企业设置而言更麻烦的是微服务最有效的运行时不一定是功能完善的应用程序服务器。 它可能只是一个servlet引擎或者JVM已经足够作为执行环境。 随着运行时变体的不断增长和编程语言选择的多样化这种发展变成了另一场操作的噩梦。 而且即使今天的开发人员在定义微服务以及如何将此设计应用于现有应用程序时也有些失落。 微服务被设计为小型无状态相互依赖且完全包含的应用程序。 理想地能够将它们部署到任何地方因为部署包含所有必需的部分。 微服务被设计得很小。 但是定义“小”是主观的。 可以使用某些估算技术例如代码行功能点用例。 但是通常“小”与大小无关。 在《构建微服务》一书中作者Sam Newman建议了几种定义微服务大小的技术它们是 足够小可以由小型敏捷开发团队拥有 在一到两个敏捷的冲刺通常两到四个星期内可重写 复杂性不需要进一步划分服务 无状态应用程序使用仅包含在其中的信息来处理每个请求。 微服务必须是无状态的并且必须在不记住来自外部系统的先前通信的情况下为请求提供服务。 微服务必须独立处理请求它可以与生态系统内的其他微服务协作。 例如在与其他微服务交互后生成唯一报告的微服务是一个相互依赖的系统。 在这种情况下仅向报告的微服务提供必要数据的其他微服务可能是独立的服务。 一个完整的堆栈应用程序可以单独部署。 它拥有自己的服务器网络和托管环境。 业务逻辑数据模型和服务接口API / UI必须是整个系统的一部分。 微服务必须是全栈应用程序。 为什么是我 “我已经经历了足够的工作下一个Java EE版本已经在开发中。 我们甚至都没有使用最新的Java EE7。有很多生产力功能即将出现我不在乎是否只要它能完成工作并且我们就可以处理就建造一个整体。 我确实了解这些想法。 我和您可能都一样喜欢Java EE并且很感兴趣地发现为什么微服务最近得到了发展。 这两个问题的答案可能不是一个简单的答案但是让我们尝试 考虑到我们行业中的所有问题以及仍然存在大量项目失败的情况完全可以理解增长和消除问题的需求。 新的炒作和改良的方法论的很大一部分是人类的成长意愿。 而且我们行业通常希望比上次做得更好而不是“永远不要触摸运行中的系统”。 因此首先要回答问题的第二部分“您可能想研究一下因为不做任何事情都不是解决方案。” 作为开发人员架构师或质量保证工程师我们基本上都注册了实时学习。 我现在只能为自己说话但这就是为什么我如此喜欢这份工作的很大一部分。 问题的第一部分不是那么容易回答。 创新和持续改进是企业和企业级项目的驱动力。 如果没有创新将存在过时且昂贵的基础架构组件例如主机系统其生存期比其运行的软件设计的寿命更长。 如果不对状态进行持续验证将存在隐式或显式的供应商锁定。 老化的中间件将获得扩展支持只有少数供应商仍将能够提供专门知识来开发它。 落后于最新标准的平台堆栈试图引入快速而肮脏的解决方案最终导致技术债务。 微服务领域最杰出发展最快的项目是开源项目。 Netflix OSSSpringCamelFabric8等是突出的例子。 通过如今的PaaS产品使用多源全栈应用程序变得容易得多这些产品也得到了Docker和Kubernetes等开源项目的支持。 在我们瞬息万变的世界中法律上导致软件更改或简单错误修复的交货时间正在缩短。 很少有企业能够在长达一个月的生产周期内工作并且对软件产生业务实际价值的需求更加明显。 这不仅适用于完全由软件驱动的公司例如UberNetFlixAmazon等。 我们需要构建具有灵活性和弹性的系统而不仅仅是效率和健壮性。 今天我们需要利用已有的资源开始构建它们。 我真的想确保您以正确的方式阅读此声明我并不是说从今天开始一切都是微服务。 但是我们应该意识到他们可以提供帮助并能够提供帮助的领域 在有意义的情况下将现有应用程序更改为新方法。 我们希望能够成为那些询问该主题的人的优秀顾问 而且Java EE不会很快推出。 它将得到补充多语言世界将在各个地方发展但是我们不会很快摆脱它。 这是个好消息。 通过从developers.redhat.com下载我的免费电子书了解有关如何将Java EE应用程序转变为微服务的更多信息。 确保重新观看有关“ Java EE微服务体系结构 ”的OReilly网络广播并关注我的blog.eisele.net了解有关WildFly Swarm Docker和带有OpenShift的 Kubernetes的更多技术信息。 翻译自: https://www.javacodegeeks.com/2015/12/microservices-java-ee.html
