网站开发近期市场,南京建设人才网站,网站的目的,怎么自己做刷东西网站介绍 刚开始时#xff0c;由于要求简单#xff0c;所以应用程序既简单又小。 随着时间要求和需求的增长#xff0c;我们的应用程序变得越来越大#xff0c;越来越复杂。 这导致将单片服务器开发和部署为一个单元。 在某种程度上#xff0c;微服务可以通过简单的应用程序回… 介绍 刚开始时由于要求简单所以应用程序既简单又小。 随着时间要求和需求的增长我们的应用程序变得越来越大越来越复杂。 这导致将单片服务器开发和部署为一个单元。 在某种程度上微服务可以通过简单的应用程序回归基础这些应用程序可以通过利用彼此之间的API一起工作来满足当今对复杂性的需求。 什么是整体服务器 与微服务相比微服务最好被解释。 整体服务器 。 它们作为一个单元开发和部署 。 对于Java最终结果通常是单个WAR或JAR文件。 C 、. NetScala和许多其他编程语言也是如此。 大多数软件开发的短暂历史都以我们开发的应用程序规模的不断增加为标志。 随着时间的流逝我们将越来越多地添加到我们的应用程序中从而不断增加它们的复杂性和大小并降低我们的开发测试和部署速度 。 随着时间的流逝我们开始将应用程序划分为多个层表示层业务层数据访问层等。这种分离比物理上更逻辑。 尽管开发变得容易一些但每次更改或发布时我们仍然需要测试和部署所有内容。 在企业环境中拥有花费数小时才能构建和部署的应用程序并不少见。 测试尤其是回归测试往往是一场噩梦在某些情况下会持续数月之久。 随着时间的流逝我们进行仅影响一个模块的更改的能力正在下降。 分层的主要目的是使它们易于替换或升级。 这个承诺从未真正实现。 在大型整体应用中更换零件几乎从来都不容易而且没有风险。 扩展此类服务器意味着扩展整个应用程序从而产生非常不平衡的资源利用。 如果我们需要更多的资源即使瓶颈是一个模块我们也被迫在新服务器上复制所有内容。 什么是微服务 微服务是一种架构和开发由小服务组成的单个应用程序的方法。 了解微服务的关键是它们的独立性 。 彼此分别开发测试和部署。 每个服务作为单独的进程运行。 不同微服务之间的唯一关系是通过它们公开的API来完成数据交换。 它们以某种方式继承了Unix / Linux中使用的小型程序和管道的思想。 大多数Linux程序很小并且会产生一些输出。 该输出可以作为输入传递给其他程序。 链接在一起时这些程序可以执行非常复杂的操作。 它是由许多简单单元组合而成的复杂性。 微服务的关键方面是 他们做一件事或负责一项功能。 每个微服务都可以通过任何一组工具或语言来构建因为它们彼此独立。 由于每个微服务在物理上是彼此分离的因此它们实际上是松散耦合的。 开发不同的微服务的不同团队之间的相对独立性假设它们公开的API是预先定义的。 简化测试以及持续交付或部署 微服务的问题之一是决定何时使用它们。 最初尽管应用程序仍然很小但是微服务试图解决的问题并不存在。 但是一旦应用程序增长并且可以提出微服务的理由切换到另一种体系结构样式的成本可能会太大。 经验丰富的团队可能从一开始就使用微服务因为他们知道他们以后可能需要偿还的技术债务比起一开始使用微服务要昂贵得多。 通常就像NetflixeBay和Amazon一样整体式应用程序开始逐渐向微服务发展。 新模块被开发为微服务并与系统的其余部分集成。 一旦证明了自己的价值现有的整体应用程序的一部分就会重构为微服务。 企业应用程序开发人员经常引起批评的一件事是数据存储的分散化。 尽管微服务可以使用集中式数据存储来工作只需进行少量调整但至少应该探索使该部分分散的选项。 将与某些服务相关的数据存储在单独的分散式存储中并将其全部打包到同一容器中的选择在许多情况下比将数据存储在集中式数据库中更好。 我们不建议始终使用分散存储而在设计微服务时考虑使用该选项。 缺点 运营和部署复杂性增加 反对微服务的主要论点是操作和部署复杂性的增加。 这种说法是正确的但是由于有了相对较新的工具它可以缓解。 配置管理CM工具可以相对轻松地处理环境设置和部署。 Docker对容器的利用大大减少了微服务可能引起的部署麻烦。 CM工具与Docker一起使我们能够轻松部署和扩展微服务。 可以在文章连续部署使用Ansible和Docker实施中找到一个示例。 在我看来增加部署复杂性的争论通常没有考虑到我们在过去几年中看到的进步并且被夸大了。 这并不意味着一部分工作不会从开发转移到DevOps 。 肯定是。 但是在许多情况下收益要大于转移带来的不便。 远程过程调用 另一个反论点是远程进程调用会降低性能。 通过类和方法进行内部调用更快并且无法解决此问题。 性能损失对系统的影响取决于具体情况。 重要的因素是我们如何拆分系统。 如果我们将非常小的微服务如果有人建议它们的LOC不应超过10-100 LOC达到极限那么这种影响可能是相当大的。 我喜欢创建围绕用户购物车产品等功能组织的微服务。这减少了远程流程调用的数量。 另外必须注意的是如果从一个微服务到另一微服务的呼叫正在通过快速内部LAN进行则负面影响相对较小。 优点 以下仅是微服务可以带来的一些优势。 这并不意味着在其他类型的体系结构中不存在相同的优势而是与微服务相比与其他一些选择相比它们可能会更加突出。 缩放比例 扩展微服务比单片应用程序容易得多。 在后一种情况下我们将整个应用程序复制到一台新机器上而在微服务中我们仅复制那些需要扩展的服务 。 我们不仅可以扩展需要扩展的内容而且可以更好地分发内容。 例如我们可以将一个CPU利用率很高的服务与另一个使用大量RAM的服务放在一起同时将第二个CPU需求服务移至其他硬件。 革新 一旦建立了初始架构单片服务器就不会留出太多的创新空间。 由于其性质更改事物会花费时间并且实验非常冒险因为它可能影响所有事物。 例如不能仅仅因为它更适合一个特定的模块就更改Apache Tomcat for NodeJS。 我并不是建议我们应该为每个模块更改编程语言服务器持久性等。 但是单片服务器趋向于相反的极端在这种极端情况下即使不是不受欢迎的更改也会带来风险。 借助微服务我们可以分别为每个服务选择我们认为最佳的解决方案 。 一个可能使用Apache Tomcat而另一个可能使用NodeJS。 一个可以用Java编写另一个可以用Scala编写。 我并不是在提倡每种服务都与其他服务有所不同但是可以以我们认为最适合当前目标的方式来进行每种服务。 最重要的是更改和实验要容易得多。 毕竟只要尊重API我们所做的一切只会影响众多微服务中的一个而不会影响整个系统。 尺寸 由于微服务很小因此更容易理解。 查看一个微服务正在做什么的代码要少得多。 这本身就极大地简化了开发尤其是当新来者加入该项目时。 最重要的是其他所有东西都趋向于更快。 与整体应用程序中使用的大型项目相比 IDE在小型项目中的运行速度更快 。 由于没有大型服务器或大量库需要加载因此启动速度更快 。 部署回滚和故障隔离 部署更快更容易 。 部署小部件总是比部署大部件更快如果不是更容易的话。 如果我们意识到存在问题则该问题的影响可能有限并且可以更轻松地回滚 。 在回滚之前 故障只隔离到系统的一小部分。 连续交付或部署可以用大型服务器无法实现的速度和频率来完成。 无需长期承诺 整体应用程序的常见问题之一是承诺。 我们经常被迫从一开始就选择会持续很长时间的体系结构和技术。 毕竟我们正在构建一些可以持续很长时间的大型项目。 对于微服务 需要长期承诺的需求并不大 。 在一种微服务中更改编程语言如果发现它是一个不错的选择则将其应用于其他微服务。 如果实验失败或不是最佳方案则仅需要重做系统的一小部分。 同样适用于框架库服务器等。我们甚至可以使用不同的数据库。 如果某些轻量级NoSQL似乎最适合特定的微服务为什么不使用它并将其打包在容器中 最佳实践 以下大多数最佳实践通常都可以应用于面向服务的体系结构。 但是借助微服务它们变得更加重要或有益。 货柜 处理许多微服务很容易成为一项非常复杂的工作。 每种都可以用不同的编程语言编写可以需要不同的服务器希望是轻量级的或可以使用不同的库集。 如果将每个服务打包为一个容器那么大多数问题将消失。 我们要做的就是使用例如Docker运行容器并相信所需的一切都在其中。 代理微服务或API网关 大型企业前端可能需要调用数十甚至数百个HTTP请求与Amazon.com一样 。 与接收响应数据相比调用请求通常花费更多时间。 在这种情况下代理微服务可能会有所帮助。 他们的目标是调用不同的微服务并返回聚合的服务。 它们不应包含任何逻辑而只是将多个响应组合在一起并以汇总数据响应给消费者。 反向代理 切勿直接公开微服务API。 如果没有某种类型的编排则消费者与微服务之间的依赖关系变得如此之大以至于它可能会消除自由而微服务应该给我们带来自由。 诸如nginx和Apache Tomcat之类的轻量级服务器非常擅长执行反向代理任务并且可以轻松地以很少的开销使用。 请查阅《 持续部署实施 》一文以了解将反向代理与Docker和其他一些工具结合使用的一种可能方式。 极简主义方法 微服务应仅包含它们真正需要的包库和框架。 它们越小越好。 这与单片应用程序使用的方法形成了鲜明对比。 以前我们可能曾经使用过像JBoss这样的JEE服务器它包装了我们可能需要或可能不需要的所有工具而微服务则可以与更简单的解决方案一起工作。 拥有数百个微服务每个微服务都具有完整的JBoss服务器这会显得过时了。 例如 Apache Tomcat是一个更好的选择。 我倾向于使用更小的解决方案例如将Spray作为一种非常轻量级的RESTful API服务器。 不要打包您不需要的东西。 同样的方法也应应用于操作系统级别。 如果我们将微服务部署为Docker容器那么CoreOS可能是比Red Hat或Ubuntu更好的解决方案。 它摆脱了我们不需要让我们更好地利用资源的事情。 必须进行配置管理 随着微服务数量的增长对配置管理CM的需求也在增加。 不用工具如Puppet Chef或Ansible 仅举几例部署许多微服务很快就成为噩梦。 实际上无论有没有微服务对于最简单的解决方案不使用CM工具都是一种浪费。 跨职能团队 虽然没有规定使用哪种类型的团队的规则但是当一个团队中的团队是多功能的时微服务才是最好的选择。 从开始设计到完成部署和维护应由一个团队负责。 它们太小无法从一个团队转移到另一个团队架构/设计开发测试部署和维护团队。 最好有一个负责微服务整个生命周期的团队。 在许多情况下一个团队可能负责多个微服务但多个团队不应该一个。 API版本控制 版本控制应该应用于任何API微服务也是如此。 如果某些更改会使API格式失效则该更改应作为单独的版本发布。 对于公共API或微服务我们无法确定谁在使用它们因此必须保持向后兼容性或者至少要给消费者足够的时间来适应。 REST API with JSON文章中发布了有关API版本控制的部分。 摘要 微服务并不能解决我们所有的问题。 没有什么是。 它们不是所有应用程序都应创建的方式。 没有适合所有情况的单一解决方案。 微服务已经存在了很长时间近年来它们的普及程度也在不断提高。 导致这种趋势的因素很多可伸缩性可能是最重要的一种。 新工具尤其是Docker的出现使我们能够从新的角度看待微服务并消除了其开发和部署所造成的部分问题。 诸如AmazonNetFlixeBay等“大佬”对微服务的利用提供了足够的信心即企业应用程序开发人员已经可以评估如果不使用这种体系结构样式。 翻译自: https://www.javacodegeeks.com/2015/01/monolithic-servers-vs-microservices.html
