admin 管理员组文章数量: 887609
2024年1月23日发(作者：terminal删除文件夹)
微服务架构及技术路线一、前言微服务（MicroServices）是一种架构风格，一个大型复杂软件应用由多个微服务和前端展示层组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。以往开发应用程序都是单体应用（可以理解为一个部署包包含了项目的所有功能），虽然开发和部署比较方便，但后期随着业务的不断增加为了能够达到响应业务需求，单体应用的开发迭代和性能瓶颈等问题愈发明显，微服务就是解决此问题的有效手段。二、什么是微服务架构微服务架构是一种架构风格，整个应用被划分并设计为以业务域为模型的松散耦合的独立服务。微服务中的“微”非常具有欺骗性，事实上它没有规定服务的规模有多小或多大。微服务架构是一个用分布式服务拆分业务逻辑，完成解耦的架构模式（架构风格）。微服务肯定是分布式的一种，是在分布式技术成熟之后，然后把分布式当成解耦手段来架构系统-----因为拆分的服务很细致，服务数量规模开始变多了，服务的体量开始缩小了，由以前几个大的服务，转变为多个独立运行的、原子性质的服务。
这里的重点是每个独立服务都有一个业务边界，可以独立开发、测试、部署、监控和扩展，甚至可以用不同的编程语言开发它们。在基于微服务的架构中，理想情况下每个组件或服务都有自己的数据库。没有集中式数据库，可以根据需要为每个单独的微服务使用NoSQL、RDBMS或任何其他数据库，这也是让微服务真正独立的原因之一。三、一体化架构的问题或者说是微服务架构所解决的问题。3.1难以扩展一体化架构应用只能通过在负载均衡器后面放置整个应用程序的多个实例来进行水平扩展。如果应用中的特定服务需要扩展，则没有简单的选项。需要完整地扩展应用程序，这显然会造成不必要的资源浪费。
相比之下，基于微服务的应用程序允许根据需要独立扩展单个服务。在上图中，如果需要缩放服务B，则可以有10个实例，同时保持其他实例，并可以根据需要随时更改。3.2交付时间长一体化架构在单个应用的任何部分/层中进行的任何更改都需要构建和部署整个应用程序。个人开发人员还需要下载整个应用程序代码来修复和测试，而不仅仅是受影响的模块，这就影响到了持续部署的效率。而在微服务架构中，如果仅在一百个微服务中的一个中需要改变，则仅构建和部署改变的微服务，没有必要部署一切。甚至可以在短时间内多次部署。3.3应用复杂性过去，随着应用规模的增长（功能、功能等），团队也会相应扩张，应用很快就就会变得复杂和交织在一起。随着不同的团队不断修改代码，维护模块化结构慢慢变得越来越困难，并慢慢导致像意大利面一样交织的代码。这不仅会影响代码质量，还会影响整个组织。在基于微服务的应用中，每个团队都在单独的微服务上工作，代码会有序很多。3.4没有明确的所有权在一体化应用中，看起来独立的团队实际上并不是独立的。它们同
时在相同的代码库上工作，严重依赖于彼此。在基于微服务的应用中，独立团队处理单独的微服务。一个团队将拥有一个完整的微服务。工作的明确所有权明确控制服务的一切，包括开发、部署和监控。3.5故障级联如果没有正确设计，一体化应用的一部分失败可能会级联并导致整个系统崩溃。在基于微服务的架构的情况下，可以使用断路器来避免这种故障。3.6Dev和Ops之间的墙开发团队通常会进行开发、测试，一旦部署，就会将维护和支持的所有权交给运维团队，应用此时与开发团队无关了，而运维团队需要努力在生产环境中支持一体化架构应用。在基于微服务的应用中，团队的组织理解为“构建它、运行它”，开发团队继续在生产中拥有该应用。3.7陷入某种技术/语言使用一体化架构，意味着被某种已实现的技术/语言锁定。如果需要更改技术/语言，则必须重写整个应用程序。使用微服务，每个服务可以根据需求和业务使用不同的技术或语言
实现。任何改变服务技术/语言的决定都只需要重写该特定服务，因为所有微服务都是相互独立的。3.8支持微服务的正确工具/技术的可用性几年前，还没有适当的工具和技术来支持微服务。但自从Docker容器和云基础设施（特别是PaaS）向大众提供服务以来，微服务正在大规模采用，因为它们提供了所需的“自由”，而无需进行传统的配置程序。四、认识微服务小结4.1微服务架构优点每个服务足够内聚，足够小，代码容易理解，开发效率高。服务直接可以独立部署，让持续部署成为可能。每个服务可以各自进行水平和垂直扩展，而且每个服务可以根据需要部署到合适的硬件和软件上。容易扩大开发团队，可以根据每个组件组织开发团队。提高容错性，一个服务的问题不会让整个系统瘫痪。系统不会长期限制在某个技术栈上。降低成本。可尽量复用已有功能，避免重复造轮子。可以大大减少项目建设过程的调研、设计、开发、测试、运维的成本。易于开发与维护：一个微服务只关心一个特定的业务功能，所以他业务清晰，代码量较少。独立开发部署服务。
局部修改容易，所以开发上线速度和灵活性。更高的代码质量。获得围绕业务功能创建/组织的代码。提高生产力。开发人员专职自己的微服务开发，对业务和代码都熟悉。更容易扩展技术栈不受限：每个服务可用不同的开发语言按需伸缩：可根据不同的需求，实现细粒度的拓展。为多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。持续集成和持续交付的应用大大提高生产力。提高开发人员生产力，开发人员只需要将代码推送到代码仓库即可。该代码将被集成，测试，部署，再次测试，与基础功能（Maven依赖）合并，经过质量审查，并准备以极高的信心进行部署。减少了手动操作的环节，极大的提高了重复工作的效率。4.2微服务的缺点运维的技术复杂度和相应的运维成本（测试、变更、部署）。必须建立开发运维一体化机制Devops。必须有完备的监控手段和自动化恢复手段。分区数据库可能带来的业务数据同步与一致性问题。微服务的接口将成为变更的敏感位（尽量保持接口的稳定性，不能
经常变化入参和出参）。运维要求高：服务更多意味着运维的投入，单体应用只需保证一个应用的正常运行，而在微服务中，需要保证几十上百的服务正常运行与协作。服务越小，独立性更好，但是相应的服务数量就越多。每个服务都需要独立的配置、部署、监控、日志收集等，成本呈指数级增长。需要更高的自动化运维策略。微服务应用作为分布式系统带来了复杂性。当应用是整体应用程序时，模块之间调用都在应用之内，即使进行分布式部署，依然在应用内调用。可是微服务是多个独立的服务，当进行模块调用的时候，分布式将会麻烦。多个独立数据库，事务的实现更具挑战性。依赖管理复杂，测试微服务变得复杂，当一个服务依赖另外一个服务时，测试时候需要另外一个服务的支持。五、微服务架构必备技术栈微服务是一种软件设计、架构思想，当然，里面也包含了相关技术点要解决当前要务。学习微服务，不能空口而谈，一定要落实到具体的技术栈上。当今使用比较多两个技术体系，一个是Java，另外一个就是Net，微服务架构里面的很多技术是和开发语言无关的，无论是.Net还是Java平台都可以使用。1、微服务架构----服务通信
WebService、WCF、WebAPI，甚至可以是ASHX,ASPX，这都是微软本身的技术体系，没什么可说的。（1）、主动触发（2）、数据序列化传递（3）、跨平台。（4）、跨语言（5）、Http穿透防火墙。2、微服务架构----进程通信（1）、NetRemoting：Net平台督邮的，不支持跨平台。（2）、gRPC：高性能、开源和通用RPC框架，面向服务端和移动端，基于HTTP/2设计，推荐使用。3、微服务架构---API网关服务（Ocelot）API网关——它是系统的暴露在外部的一个访问入口。这个有点像代理访问的家伙，就像一个公司的门卫承担着寻址、限制进入、安全检查、位置引导、等等功能。Ocelot是一个用.NETCore实现并且开源的API网关，它功能强大，包括了：路由、请求聚合、服务发现、认证、鉴权、限流熔断、并内置了负载均衡器与ServiceFabric、ButterflyTracing集成。
API统一管理对业务系统的API进行封装，对外提供统一标准接口，登录系统，API详情，一目了然。统一基础功能实现，一次投入，大家共用提供安全，缓存，转换，日志，流控，过滤等非功能的统一服务。管理API生命周期管理标准化API的创建，发布，下线，文档，方便审计API的历史变化。
内外网隔离内外网隔离，通过白名单或校验规则，对访问进行了初步的过滤。相比防火墙，这种软件实现的过滤规则，更加动态灵活。4、微服务架构—认证&授权现在的应用开发层出不穷，基于浏览器的网页应用，基于微信的公众号、小程序，基于IOS、Android的App，基于Windows系统的桌面应用和UWP应用等等，这么多种类的应用，就给应用的开发带来的挑战，除了分别实现各个应用外，还要考虑各个应用之间的交互，通用模块的提炼，其中身份的认证和授权就是每个应用必不可少的的一部分。而现在的互联网，对于信息安全要求又十分苛刻，所以一套统一的身份认证和授权就至关重要。
版权声明：本文标题：微服务架构及技术路线 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.freenas.com.cn/jishu/1705995281h497148.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论