.Net微服务实战之技术架构分层篇(一)

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: .Net微服务实战之技术架构分层篇(一)

一拍即合

  

上一篇《.Net微服务实战之技术选型篇》,从技术选型角度讲解了微服务实施的中间件的选择与协作,工欲善其事,必先利其器,中间件的选择是作为微服务的基础与开始,也希望给一直想在.Net入门微服务的同行有一个很好的方向。


在此篇重新整理了一下整个微服务项目的demo,希望对有需要的朋友起到一定的帮助:https://github.com/SkyChenSky/Sikiro 

  

那么我在公司实施微服务的时候,也不是一拍脑袋想上就上的。刚入职公司的时候才3、4个人,产品给到我的规划只有一个很简单的系统


包含权限、客服IM、内容管理三个模块,我当时想着优先证明我们的开发能力和效率,于是使用简单的单体架构不到三个星期项目就完成了。产品在我们开发的期间把整个项目的规划和平台系统的划分给梳理了一遍


终于让我有一个很明确的技术实施方向,同时公司的人力成本预算也批了下来开始进行团队扩招。

  

于是我与老领导商量了一下,在现在这个情况,无论业务还是团队都具有使用微服务架构的可操作性,再采用部分DevOps的思想给与微服务实施的支持,能顺利的实施落地微服务问题不大。


我们俩讨论了一番,我有良好的微服务技术储备,他有很好的运维支撑,就这样咱两达成了共识。


于是我着手翻出了收藏已久的微服务中间件、架构分层、服务拆分的资料,从此开始了我的微服务实施之路。


PS:我们讨论实施微服务的时候除了以上冠冕堂皇的理由之外,其实还存有一点私心,就是现在企业招聘很多需要有实施微服务经验的人才,但是80%的项目和同行又是没有这样的实施必要与经验,这就是鸡生蛋和蛋生鸡的问题。


我毫无隐瞒的说出我们的私心并不是怂恿大家冒着风险去实施,而是希望大家通过分析现在团队的组织架构、技术储备、业务架构,在条件允许的情况下满足您的小小要求,微服务虽不是银弹,但我们也需要成长。


架构思维

  

抽象是作为架构思维的核心,使我们站在大局观察,屏蔽细节;这系统划分哪几个模块?模块之间的如何协作的?抽象又可以衍生出两种思想划分与协作。

  

划分的目的是为了定责与拆分,定责不是交通事故的定责而是划定职责,明确模块的使用场景,应该被什么依赖?应该依赖什么?拆分其实就是分而治之的思想,把一个复杂的大问题拆分成一个个简单而小的问题,化繁为简逐个击破自然就迎刃而解。

  

协作的目的是整合划分好的模块,被拆分的模块如果无法整合到一起,拆分则失去了他原有的意义。


image.png


不谋而合

  

技术服务于架构,架构服务于业务,业务服务于商务。所以有明确的业务蓝图才可以很好的规划架构方向;选择好合适的技术才能很好的支撑架构。


此时我们开始着手实施微服务,然而在实施时我们还会考虑一个比较核心点,究竟如何微?粒度究竟到什么程度?怎么明确依赖关系?大家或多或少都会听说身边同行有实施微服务的失败案例:拆分粒度过细导致系统复杂度过高;拆分粒度太粗又没达到微服务该有的效果等。


那么是否在业界有一套科学的指导方法论?我认为是有的,DDD战略设计分层架构。

  

埃里克、埃文斯在2004年发表了《领域驱动设计》一书的,此后一直是雷声大雨点小,在2014年软件教父马丁花给微服务一个全面描述,让它走向一个高潮后,DDD终于赢来了他的春天。


为什么说DDD适合微服务呢?DDD是一种通过划分业务边界,将复杂的业务领域简单化的设计思想,也就是化繁为简。为什么在上文重点强调DDD战略设计?DDD分为战略设计战术设计。


战略设计

  

主要从业务视角出发,建立业务领域模型,划分领域边界,建立通用语言的界限上下文,界限上下文可以作为微服务设计的参考边界。


战术设计

  

主要从技术视角出发,侧重于领域模型的技术实现,完成软件开发和落地,例如我们常讨论的聚合根、实体、值对象、领域服务等代码逻辑的设计与实现。

  

从以上两点的描述可以看出,战略设计从业务视角出发,而架构服务于业务,两者都需要从业务出发,DDD战略设计微服务都有同样的设计思想:分而治之、化繁为简,那么战略设计的思想完全可以作为微服务架构设计的指导思想,此时此刻此场景不谋而合。


分层&切割

  

也可以叫N层架构(N>=2),其实本质在于划分职责、隔离关注点,保证各层之间的差异足够清晰,边界足够明显,其特点自顶向下依赖,逐层传递。


image.png



目录
相关文章
|
11天前
|
API 数据库 开发者
构建高效可靠的微服务架构:后端开发的新范式
【4月更文挑战第8天】 随着现代软件开发的复杂性日益增加,传统的单体应用架构面临着可扩展性、维护性和敏捷性的挑战。为了解决这些问题,微服务架构应运而生,并迅速成为后端开发领域的一股清流。本文将深入探讨微服务架构的设计原则、实施策略及其带来的优势与挑战,为后端开发者提供一种全新视角,以实现更加灵活、高效和稳定的系统构建。
18 0
|
10天前
|
Kubernetes 安全 Java
构建高效微服务架构:从理论到实践
【4月更文挑战第9天】 在当今快速迭代与竞争激烈的软件市场中,微服务架构以其灵活性、可扩展性及容错性,成为众多企业转型的首选。本文将深入探讨如何从零开始构建一个高效的微服务系统,覆盖从概念理解、设计原则、技术选型到部署维护的各个阶段。通过实际案例分析与最佳实践分享,旨在为后端工程师提供一套全面的微服务构建指南,帮助读者在面对复杂系统设计时能够做出明智的决策,并提升系统的可靠性与维护效率。
|
2天前
|
机器学习/深度学习 运维 Prometheus
探索微服务架构下的系统监控策略
【4月更文挑战第18天】在当今快速迭代和持续部署盛行的软件工程实践中,微服务架构因其灵活性和可扩展性受到企业青睐。然而,随着服务的细粒度拆分和网络通信的增加,传统的监控手段已不再适用。本文将探讨在微服务环境中实施有效系统监控的策略,包括日志聚合、性能指标收集、分布式追踪以及异常检测等关键技术实践,旨在为读者提供构建稳定、可靠且易于维护的微服务系统的参考指南。
7 0
|
2天前
|
监控 持续交付 开发者
构建高效微服务架构:后端开发的新趋势
【4月更文挑战第18天】在数字化转型的浪潮中,微服务架构已成为企业提升系统灵活性、加速产品迭代的关键。此文深入探讨了构建高效微服务架构的实践方法,包括服务划分原则、容器化部署、持续集成/持续部署(CI/CD)流程以及监控与日志管理等关键技术点。通过分析具体案例,揭示了微服务在提高开发效率、降低维护成本及促进团队协作方面的显著优势。
|
3天前
|
负载均衡 Java 开发者
细解微服务架构实践:如何使用Spring Cloud进行Java微服务治理
【4月更文挑战第17天】Spring Cloud是Java微服务治理的首选框架,整合了Eureka(服务发现)、Ribbon(客户端负载均衡)、Hystrix(熔断器)、Zuul(API网关)和Config Server(配置中心)。通过Eureka实现服务注册与发现,Ribbon提供负载均衡,Hystrix实现熔断保护,Zuul作为API网关,Config Server集中管理配置。理解并运用Spring Cloud进行微服务治理是现代Java开发者的关键技能。
|
4天前
|
监控 JavaScript 安全
构建微服务架构下的API网关
【4月更文挑战第15天】在微服务架构中,API网关扮演着至关重要的角色。它作为系统的唯一入口,不仅负责请求的路由、负载均衡和认证授权,还涉及到监控、日志记录和服务熔断等关键功能。本文将探讨如何构建一个高效且可靠的API网关,涵盖其设计原则、核心组件以及实现策略,旨在为后端开发人员提供一套实用的指导方案。
19 4
|
5天前
|
监控 负载均衡 API
构建高性能微服务架构:后端开发的最佳实践
【4月更文挑战第14天】 在当今快速发展的软件开发领域,微服务架构已成为构建可扩展、灵活且容错的系统的首选方法。本文深入探讨了后端开发人员在设计和维护高性能微服务时需要遵循的一系列最佳实践。我们将从服务划分原则、容器化部署、API网关使用、负载均衡、服务监控与故障恢复等方面展开讨论,并结合实际案例分析如何优化微服务性能及可靠性。通过本文的阅读,读者将获得实施高效微服务架构的实用知识与策略。
|
7天前
|
运维 监控 自动驾驶
构建可扩展的应用程序:Apollo与微服务架构的完美结合
构建可扩展的应用程序:Apollo与微服务架构的完美结合
30 10
|
13天前
|
运维 负载均衡 网络协议
探索微服务架构下的服务发现机制
【4月更文挑战第6天】 随着现代软件工程的发展,微服务架构因其灵活性、可扩展性而日益受到重视。在此架构模式下,服务发现成为了确保系统高可用性和弹性的关键组件。本文将深入探讨微服务环境中服务发现的核心概念、实现方式以及面临的挑战,旨在为开发者提供一套明晰的服务发现指南和实践建议。
|
16天前
|
消息中间件 监控 API
构建高性能微服务架构:从理论到实践
【4月更文挑战第4天】 在当今互联网应用的快速迭代和高并发需求下,传统的单体应用架构已不足以满足市场的灵活性与扩展性要求。微服务架构以其独立部署、弹性伸缩、技术多样性等优势,成为众多企业转型升级的首选方案。本文将深入探讨如何构建一个高性能的微服务系统,涵盖关键组件的选择、系统设计的考量以及性能优化的策略,旨在为开发者和架构师提供一套实用的指导思路和具体实践步骤。