跟我学Devops之思想篇（二）

最新推荐文章于 2024-09-25 17:53:40 发布

Rugod

最新推荐文章于 2024-09-25 17:53:40 发布

阅读量315

点赞数 1

分类专栏： Devops 文章标签：运维 devops

本文链接：https://blog.csdn.net/itrugod/article/details/106962052

版权

Devops 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

声明:这是我在大学毕业后进入第一家互联网工作学习的内容

微服务架构简介

百度解释

微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台，使部署、管理和服务功能交付变得更加简单。

使用微服务构建现代化应用程序是很有意义的，因为它让你既利用了扩展横向扩展架构，也利用纵向扩展架构；还额外得到API的组合，且在整个业务中可重复利用。

个人从工作中理解什么叫微服务架构

一个公司的核心业务购买商品系统用微服务架构和传统架构

用微服务框架是这样的

一个登陆注册功能，一个查询商品功能，一个商品库存功能，一个购买功能，这些功能通过API互相调用，并且每个功能能做成独立的应用分别部署到容器里上，一个容器挂掉/更新不会影响整个项目的运行。
用这种框架的好处在于在这个系统第一次上线到生产环境后并且能保持核心业务正常运行的情况下，项目后期的更新只是某个功能应用的更新，不会影响整个生产环境的稳定性。
如果你只需要改一个查询商品的功能，即使这个功能后期上线的时候出现了逻辑问题，但是也不会影响核心流程（购买），并且你可以通过容器编排工具kubernetes快速将这一个功能回滚到上一个版本。

用传统框架是这样的
所有的功能写到一个应用中，启动慢，内容太多，后期更新迭代只会越来越难，上线部署风险大（需要重启整个大项目），特别得出现了逻辑问题需要技术人员定位问题，以及回退项目，造成用户体验不好。

举个简单的例子，如果支付宝、微信这样的大应用用传统框架更新，更新完发现某个功能不能用需要回退重启，造成了短暂几分钟不能打开应用，这种损失是无法估量的。而用微服务架构，即使更新后出现了问题，也只会找更新的那个应用组件，定位问题+回退重启，这种方式可以在用户无感知的情况下进行，影响也会小很多。

Devops和微服务的关系

一些企业总是避开定期投资架构解耦和现代化技术，因此现在无法摆脱巨大的产品架构，使得发布变成无法预测。从某种程度上来说，微服务架构和Devops相辅相成，devops和微服务架构的存在都是为了解决这么一个问题：全世界的所有组织都试图频繁地发布高质量的产品，来提高客户的满意度。

微服务架构和DevOps允许分散开的团队控制他们自己的命运

微服务架构就是关于把一件事做好，从设计一个由许多“服务”集中到一个的庞然大物中，这是一种范式转变。对庞大系统的扼杀催生了更小的微服务，并加速了庞大笨重团队的瓦解，研发变成了多个更小（更灵活）的团队。

此外，权力分散也正好符合DevOps的核心原则，缩小了两者之间的差距：

UI、中间层和后台专家，他们倾向于在自己的筒仓中操作。
业务、产品管理、开发、QA、发布、安全、运营，以及其他成员，这些人都倾向于在自己的部门工作。

最重要的是，微服务架构和DevOps都支持产品模型和项目模型，即5-7个成员团队设计、构建、测试、发布、监控和维护他们在开发/测试、阶段和生产上的应用。

区分开的服务可以作为独立的、可展开的构件发布

大多数组织都倾注于设计和实施有弹性的持续交付管道，这可以帮助他们：在一个安全的、受保护的和可审计的方式下测试新功能。
很快从失败中恢复，而不去影响客户。

尽管整体架构模式是成功的，但微服务提供的模块性使发布能够快速地以增量的方式进行。DevOps也支持小批量的规模，并允许小型团队拥有服务并将其交付。这样的设计能使微服务和DevOps在和谐地发挥作用，以帮助组织扩大规模。

微服务和DevOps提高了测试周期，并且加速推向市场

一些组织常常面临激烈的竞争，或者至少是保持不掉队。他们想建立可持续的商业模式，这样就可以让新想法迅速付诸实践，而不会消磨团队精力。然而，用庞大僵化的系统来实现这一目标是有可能的，但与颗粒状的微服务相比，可能性要小得多。下面就是原因。

一个庞然的系统经常导致一场“庞大测试”：

系统在重要的一段时间内被设计和实施，在此期间团队成员可能多次改动。
可能不允许单独测试，因为测试用例、设计测试数据和测试配置没有被设计用来独立执行。
由于添加新的测试用例，每个新版本就越来越大。有时候，即使是在生产中不常用的功能，也会有缓慢的、归档的过期测试。在测试存档过程中可能存在不确定性，因为可能没有一个人完全理解系统架构。

颗粒度的微服务通过独立的、可部署版本的构建被发布到生产中，这些构件分别被验证。微服务相互作用，提供特定的客户用例，因此需要智能集成测试。在集成测试期间，这些邻近的服务中有一些是由它们的测试替身和清晰定义的合约来表示的。测试替身和合约应该被重视，并且应该由拥有、交付和维护真实服务和接口的小团队拥有。

微服务架构面临的挑战

运维开销。更多的服务也就意味着更多的运维，产品团队需要保证所有的相关服务都有完善的监控等基础设施，传统的架构开发者只需要保证一个应用正常运行，而现在却需要保证几十甚至上百道工序高效运转，这是一个艰巨的任务。
DevOps要求。使用微服务架构后，这就意味着团队需要高品质的DevOps和自动化技术。而现在，这样的全栈式人才很少。
隐式接口。服务和服务之间通过接口来“联系”，当某一个服务更改接口格式时，可能涉及到此接口的所有服务都需要做调整。
重复劳动。在很多的服务中可能都会使用到同一个功能，而这一功能点没有足够大到提供一个服务的程度，这个时候可能不同的服务团队都会单独开发这一功能，重复的业务逻辑，这违背了良好的软件工程中的很多原则。
分布式系统的复杂性。微服务通过REST API或消息来将不同的服务联系起来，这在之前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等，而面对如此多的微服务都需要分布式时，整个产品需要有一整套完整的机制来保证各个服务可以正常运转。