
点击上方蓝字,关注灸哥!

点击上方蓝字,关注灸哥!

随着软件行业的快速发展,传统的单体应用架构逐渐暴露出其固有的问题,比如部署困难、扩展性差、维护成本高等,而微服务架构作为一种新的架构模式,逐渐成为企业内解决这些问题的最佳实践方案。
微服务被定义为通过多个小型服务的组合构建单个应用的架构风格,这些服务围绕业务能力而非特定技术标准构建,可以采用不同的编程语言、数据存储技术,运行在不同的进程中。
微服务架构是一种将大型复杂软件系统应用划分为一组小的、独立的服务模块的方法,每个服务运行在其独立的进程中,并通过轻量级的通信机制相互通信。这些服务围绕业务场景构建,并通过自动化部署机制独立地开发、测试、部署和扩展。
Organized around Business Capabilities
强调康威定律的重要性。
团队的结构、规模和能力将产生对应的产品结构、规模和能力。
团队和产品磨合稳定后,将拥有一致的结构,避免了跨团队沟通和高成本的跨团队边界。
Decentralized Governance
倡导谁负责谁治理。
开发团队直接对服务运行质量负责,不受外界干预,可以选择和其他服务异构的技术来实现自己的服务。
强调对技术栈的选择权,并不强迫统一。
Componentization via Services
强调通过服务而不是类库来构建组件。
服务组件通过远程调用提供功能,带来隔离与自治的能力。
服务的独立性是通过远程调用的代价来实现的。
Products not Projects
将架构看作是一种持续改进和提升的过程。避免将软件研发视为完成某种功能的任务。
开发团队应为整个软件产品的生命周期负责,强调软件的持续改进和用户反馈。
Decentralized Data Management
将数据按领域分散管理、更新、维护和存储。
不同服务对同一数据实体的抽象形态可能是不同的,避免了中心化存储导致的服务互相影响和失去独立性的问题。
Smart Endpoints and Dumb Pipes
倡导简单直接的通信方式。
通过类似于 Unix 过滤器的简单通信方式,比如 RESTful 风格,实现服务之间的通信。
Design for Failure
接受服务总会出错的现实。
在设计中要考虑自动故障检测、隔离和服务恢复的机制。
目的是防止服务的崩溃引发雪崩效应。
可靠系统完全可以由会出错的服务来组成,这也是微服务架构最大的价值所在。
Evolutionary Design
服务应该能被淘汰,而不是长期存在。
良好的设计应该是可演进的,不可更改和无可替代的服务反映了系统设计的脆弱性。
微服务强调独立自治,鼓励设计能够随着需求的变化而演进。
Infrastructure Automation
基础设施的自动化(如 CI/CD)降低了构建、发布、运维的复杂性。
面对微服务的数量级增长,团队更加依赖基础设施的自动化来应对挑战。
Single Responsibility Principle
每个微服务应该只关注一个特定的业务功能或者能力,并保持其职责的单一性。
降低服务的复杂性,提高可维护性和可测试性。
Service Autonomy Principle
每个微服务应该具有自己独立的数据库和数据管理策略,实现服务的自治性。
降低服务之间的耦合度。
Loose Coupling & Strong Cohesion
要求微服务之间应该保持松耦合的关系,通过定义清晰的接口来进行通信。每个服务内部应该实现强內聚,将相关的功能和数据紧密地组织在一起。
提高服务的可维护性和可扩展性。
独立性:每个服务都可以独立开发、测试和部署,提高开发效率
模块化:每个服务之间低耦合、高内聚,易于维护和扩展
技术异构性:每个服务不囿于技术栈的选择,都可以选择最适合自己的技术栈,提高了系统的灵活性
容错性:某个服务的故障不会导致整个系统的瘫痪,提高了系统的稳定性
微服务架构需要处理分布式系统的复杂性,比如数据一致性、分布式事务、网络延迟等,这些在微服务架构中依旧是比较高的复杂度,对架构师有着很大的挑战。
微服务架构没有统一的规范和约束,各种中间件层出不穷,服务注册发现、负载均衡、认证授权等问题需要根据具体情况选择适当的解决方案。微服务时代的中间件百花齐放,架构师需要具备对这些工具和框架的熟悉程度,以便做出明智的选择。
微服务架构模式的企业需要建立成熟的自动化部署和监控机制,无形之中增加了运维的难度和成本。
服务网格的普及:服务网格是一种用与处理服务间通信的基础设施层。通过将通信逻辑从业务代码中解耦出来,服务网格可以提供更强大、更灵活的通信管理功能。
智能化运维的崛起:微服务架构的复杂性给运维工作带来了巨大挑战。未来,智能化运维将成为解决这个问题的关键,通过利用人工智能和机器学习技术,智能化运维可以自动分析系统日志、性能指标等数据,预测潜在问题并提前进行干预,从而确保系统的稳定运行。
混合云和多云部署的增多:随着云计算计算的不断发展,混合云和多云部署已成为企业应用部署的新趋势,微服务架构由于其天然的分布式特性,更容易实现跨云平台的部署和管理。
无服务器计算的融合:无服务器计算是一种新兴的计算模式,允许开发者无需关心底层服务器的运维和管理,只需要关注业务逻辑的实现。
重视架构设计和治理
提升开发和运维协作能力
关注安全和合规性问题
是一种用于设计、开发、部署和维护微服务应用程序的技术支持和工具集合。它提供了一套完整的解决方案,包括服务拆分、服务通信、服务治理、服务监控等方面的功能和组件,支持微服务架构的实施。
好的技术框架可以简化开发过程、提高开发效率、确保系统的可伸缩性和可靠性、促进团队协作和交付。
常用框架:Spring Boot、Spring Cloud、Dubbo、gRPC、Istio、Apache Thrift、Kubernetes
微服务架构风格在提高系统可伸缩性、灵活性和可维护性的同时也带来了服务之间通信的挑战。由于服务是分布式的,因此需要一种高效、可靠的通信机制来协同工作,满足业务需求。
同步通信方式:是指客户端发送请求后,等待服务端处理完毕并返回结果。这种通信方式具有实时性高的特点,但可能会因为服务端处理时间过长而导致客户端阻塞。常见的同步通信协议包括 HTTP/REST 和 RPC。
异步通信方式:是指客户端发送请求后,无需等待服务端处理完毕即可继续执行其他任务。当服务端处理完毕后,会通过某种方式通知客户端。这种通信方式可以降低系统的耦合度,提高并发处理能力,但可能会增加系统的复杂性和实现难度。常见的异步通信方式包括消息队列和事件驱动两种实现方式。
由于微服务架构的分布式特性,传统的单体应用数据管理方式不再适用。需要采用一些特定的数据管理策略来确保数据的一致性、可用性和可扩展性。
数据库每个服务实例:每个微服务实例都有自己的数据库实例。这确保了微服务的独立性和隔离性,因为每个服务都可以独立地控制其数据,可以做到服务之间解耦,易于扩展和维护,但是可能导致数据冗余和不一致性,因为相同的数据可能需要在多个服务中复制。
共享数据库:多个微服务实例共享同一个数据库实例。这可以减少数据冗余和不一致性,但可能会增加服务之间的耦合性。
Saga 模式:是一种处理微服务中分布式事务的模式。它允许一系列本地事务在一个全局事务中协同工作,以确保数据的一致性。通过补偿事务来处理失败的情况,即如果一个本地事务失败,它会触发一个补偿事务来撤销已经完成的本地事务的影响。虽然保证了数据的一致性,而且处理了分布式事务的复杂性,但是增加了实现的复杂性,需要额外处理补偿事务和失败的情况。
CQRS 模式:将数据查询操作(Query)和数据修改操作(Command)分离的设计模式。可以优化数据的读写性能,同时保持数据的一致性。虽然提高了系统的性能和可扩展性,而且优化了数据库的读写操作,但是增加了系统的复杂性,需要额外处理两个模型之间的数据同步问题。
事件驱动架构:微服务通过发布和订阅事件来进行通信和数据交换。当一个微服务的数据发生变化时,它会发布一个事件到事件总线或消息队列中,其他感兴趣的微服务可以订阅这个事件并相应地更新它们的数据。实现了微服务之间的解耦和异步通信,提高了系统的灵活性和可扩展性,但是需要处理事件的一致性和顺序性问题,以及可能的事件丢失或者重复问题。
微服务架构中的安全保障策略是确保整个系统安全、可靠运行的关键。
身份验证是验证用户或服务的身份,确保只有合法的用户或服务能够访问系统。常见的身份验证方法包括用户名/密码、数字证书、多因素认证等。
授权是控制用户或服务对系统资源的访问权限。通过角色、权限等机制,确保用户或服务只能访问其被授权的资源。
API 网关:是微服务架构中的入口点,用于处理所有进入微服务的请求。它可以实现身份验证、授权、限流、熔断等安全功能,有效保护后端微服务免受恶意攻击。通过 API 网关,可以实现统一的安全管理,减少每个微服务单独处理安全问题的复杂性。
加密与签名:
加密是对敏感数据进行加密存储和传输,确保数据在传输和存储过程中不被泄露。常见的加密算法包括 AES、RSA 等。
签名是对消息进行签名,验证消息的完整性和来源。签名可以防止消息在传输过程中被篡改或伪造。
安全审计与日志:记录和分析系统操作日志,检测异常行为和潜在的安全威胁。通过安全审计,可以及时发现和处理安全问题,提高系统的安全性。日志分析还可以帮助开发人员定位系统性能瓶颈和优化点,提高系统的整体性能。
网络隔离与防火墙:网络隔离技术可以将微服务部署在不同的网络区域,限制不同区域之间的直接通信。这可以有效防止恶意攻击在网络内部传播。
防火墙可以监控和过滤进出网络的流量,阻止未经授权的访问和恶意攻击。
漏洞扫描与修复:定期对微服务进行漏洞扫描,发现潜在的安全漏洞并及时修复。漏洞扫描工具可以自动化地检测常见的安全漏洞,如 SQL注入、跨站脚本攻击等。及时修复已知漏洞是防止恶意攻击的重要措施之一。
容器与虚拟化安全:在使用容器和虚拟化技术时,需要注意相关的安全问题。例如,限制容器的权限、隔离容器之间的网络通信等。确保容器和宿主机的安全更新和补丁及时应用,以防止已知的安全漏洞被利用。
大家应该都是经历过单体架构和微服务架构的人,那我们一起来聊聊他们二者的区别?
单体架构和微服务架构无论优劣,各有优缺点,选择哪种架构模式取决于实际需求和团队的实际情况,在评估时,需要综合考虑项目的规模、复杂性、开发周期、团队规模和技术能力的因素。
你在实际进行微服务架构设计与落地过程中,遇到的挑战有哪些?你是怎么解决的?
欢迎留言和灸哥交流~


▲ 点击标题查看原文
往期回顾


长按二维码识别关注
关注灸哥
了解更多
你的赞和在看,我统统都要
