要搭建网站,谷歌play商店,网页设计配色方案,网站建设会议讲话一拍即合上一篇《.Net微服务实战之技术选型篇》#xff0c;从技术选型角度讲解了微服务实施的中间件的选择与协作#xff0c;工欲善其事#xff0c;必先利其器#xff0c;中间件的选择是作为微服务的基础与开始#xff0c;也希望给一直想在.Net入门微服务的同行有一个很好… 一拍即合 上一篇《.Net微服务实战之技术选型篇》从技术选型角度讲解了微服务实施的中间件的选择与协作工欲善其事必先利其器中间件的选择是作为微服务的基础与开始也希望给一直想在.Net入门微服务的同行有一个很好的方向。在此篇重新整理了一下整个微服务项目的demo希望对有需要的朋友起到一定的帮助https://github.com/SkyChenSky/Sikiro 那么我在公司实施微服务的时候也不是一拍脑袋想上就上的。刚入职公司的时候才3、4个人产品给到我的规划只有一个很简单的系统包含权限、客服IM、内容管理三个模块我当时想着优先证明我们的开发能力和效率于是使用简单的单体架构不到三个星期项目就完成了。产品在我们开发的期间把整个项目的规划和平台系统的划分给梳理了一遍终于让我有一个很明确的技术实施方向同时公司的人力成本预算也批了下来开始进行团队扩招。 于是我与老领导商量了一下在现在这个情况无论业务还是团队都具有使用微服务架构的可操作性再采用部分DevOps的思想给与微服务实施的支持能顺利的实施落地微服务问题不大。我们俩讨论了一番我有良好的微服务技术储备他有很好的运维支撑就这样咱两达成了共识。于是我着手翻出了收藏已久的微服务中间件、架构分层、服务拆分的资料从此开始了我的微服务实施之路。PS:我们讨论实施微服务的时候除了以上冠冕堂皇的理由之外其实还存有一点私心就是现在企业招聘很多需要有实施微服务经验的人才但是80%的项目和同行又是没有这样的实施必要与经验这就是鸡生蛋和蛋生鸡的问题。我毫无隐瞒的说出我们的私心并不是怂恿大家冒着风险去实施而是希望大家通过分析现在团队的组织架构、技术储备、业务架构在条件允许的情况下满足您的小小要求微服务虽不是银弹但我们也需要成长。架构思维 抽象是作为架构思维的核心使我们站在大局观察屏蔽细节这系统划分哪几个模块模块之间的如何协作的抽象又可以衍生出两种思想划分与协作。 划分的目的是为了定责与拆分定责不是交通事故的定责而是划定职责明确模块的使用场景应该被什么依赖应该依赖什么拆分其实就是分而治之的思想把一个复杂的大问题拆分成一个个简单而小的问题化繁为简逐个击破自然就迎刃而解。 协作的目的是整合划分好的模块被拆分的模块如果无法整合到一起拆分则失去了他原有的意义。不谋而合 技术服务于架构架构服务于业务业务服务于商务。所以有明确的业务蓝图才可以很好的规划架构方向选择好合适的技术才能很好的支撑架构。此时我们开始着手实施微服务然而在实施时我们还会考虑一个比较核心点究竟如何微粒度究竟到什么程度怎么明确依赖关系大家或多或少都会听说身边同行有实施微服务的失败案例拆分粒度过细导致系统复杂度过高拆分粒度太粗又没达到微服务该有的效果等。那么是否在业界有一套科学的指导方法论我认为是有的DDD战略设计与分层架构。 埃里克、埃文斯在2004年发表了《领域驱动设计》一书的此后一直是雷声大雨点小在2014年软件教父马丁花给微服务一个全面描述让它走向一个高潮后DDD终于赢来了他的春天。为什么说DDD适合微服务呢DDD是一种通过划分业务边界将复杂的业务领域简单化的设计思想也就是化繁为简。为什么在上文重点强调DDD战略设计DDD分为战略设计与战术设计。战略设计 主要从业务视角出发建立业务领域模型划分领域边界建立通用语言的界限上下文界限上下文可以作为微服务设计的参考边界。战术设计 主要从技术视角出发侧重于领域模型的技术实现完成软件开发和落地例如我们常讨论的聚合根、实体、值对象、领域服务等代码逻辑的设计与实现。 从以上两点的描述可以看出战略设计从业务视角出发而架构服务于业务两者都需要从业务出发DDD战略设计与微服务都有同样的设计思想分而治之、化繁为简那么战略设计的思想完全可以作为微服务架构设计的指导思想此时此刻此场景不谋而合。分层架构 也可以叫N层架构N2其实本质在于划分职责、隔离关注点保证各层之间的差异足够清晰边界足够明显其特点自顶向下依赖逐层传递。纵向拆分 首先我按照分层架构的思想以纵向维度拆分主要共分5层UI层、聚合API服务层、基础业务API服务层、基础设施层、数据库层。 调用链路自顶往下用户--UI--API网关--聚合API服务--ConsulConsul TemplateNginx--业务API服务--数据库 UI层 依赖于聚合API服务层操作与接口11对应主要负责可见即可得的工作数据展示、交互动画等。 入站API网关 主要负责聚合API服务层内外网隔离、入站规则控制防止外部大流量冲垮内部服务。 聚合API服务层 被UI层依赖依赖于基础业务API服务层主要负责基础业务API服务层的接口的逻辑组合不直连数据库可通过API网关暴露给UI层调用。 注册服务中心 记录基础业务API服务层的服务IP列表内网使用衔接聚合API服务层与基础业务API服务层。 基础业务API服务层 被聚合API服务层依赖依赖于数据库层可做具体的数据库读写处理内网使用同层服务之间不互相依赖引用。 数据库层 包括非关系型数据库与关系型数据库。 基础设施服务层 可被所有层都依赖如果被UI层依赖则通过API网关暴露如果被内网服务依赖则通过注册发现可直连数据库。 出站API网关 主要负责基础设施服务层内外网隔离转发第三方开放API请求出站规则控制防止被无法把控的第三方服务而拖垮内部服务。 横向拆分 接下来我们可以通过DDD划分领域的方式进行服务的横向维度的拆分。举个例子 我们平台拥有三种不同业务领域的系统客户中心、企业管理系统、内部管理系统。 那么聚合API服务层则拥有客户系统API服务、企业管理系统API服务内部管理系统API服务。 客户中心的拥有客户信息管理、支付、订单管理等业务模块。 企业管理系统拥有订单管理、权限管理、支付、仓储等业务模块。 内部管理系统拥有权限管理、报表、账户管理等业务模块。 所有系统涉及到自定义订单号、消息推送等业务。 从以上得知核心域包括仓储、订单业务、客户信息。通用域包括权限管理、账户认证、支付模块、消息推送等。支撑域包括自定义订单号。 因此基础业务API层可以划分仓储API服务、订单API服务、客户API服务、权限API服务、认证API服务支付API服务。 基础设施API层可以划分ID发号API服务消息推送API服务。 如果随着业务继续扩大团队人数增多则可以更加的细分例如仓储拆分成快运、集运等。支付拆分成微信支付、支付宝等。 项目示例 上一篇《.Net微服务实战之技术选型篇》我整理了我们公司使用的框架开源到了github这次我拿了部分业务项目作为示例并上传了。 https://github.com/SkyChenSky/Sikiro 首先想说明几点 1.这个不是标准只是针对我们公司情况取舍后的结果每个公司的业务有复杂有简单大家视情况完善自己的项目。 2.为了保护公司原有的业务隐私我做了部分逻辑的删除所以大家如果看到不完整的逻辑是正常现象。 3.希望大家把思维放高不要死抠细节求同存异。 4.代码在原有的基础上修改了名称和引用路径会有变化如果有问题随时在评论和github反馈给我。
