精华内容
下载资源
问答
  • 模块划分是这样做吗?你们有没有这样的苦恼,当我们自己想设计一个基础框架的时候需要做模块划分,但是该怎样去划分模块?先简单的说说大众所想的微服务框架模块划分;一般的设计思路:先确定基础框架...

    模块划分是这样做吗?

    你们有没有这样的苦恼,当我们自己想设计一个基础框架的时候需要做模块划分,但是该怎样去划分模块?先简单的说说大众所想的微服务框架模块划分;

    一般的设计思路:

    • 先确定基础框架,比如SpringBoot/Dubbo/ServiceComb,然后经过调研对比选择合适的版本;

    • 选择微服务中间件注册中心、配置中心、缓存、网关等一些列组件;

    • 然后集成基础功能组件,比如数据库访问、事务、代码生成、异常处理、防重幂等等功能;

    • 基于基础框架开发一些系统比如分布式锁、分布式缓存、异步服务等基础服务;

    • 提供框架工具类,比如文件处理、格式化、日期等工具类;

    • 开发完成之后做样例项目集成;

    模块可能这样划分:

    • 会确定一个统一管理三方库的模块,用于管理第三方组件库的版本;

    • 会确定一个统一管理二方库的模块,用于管理框架相关的版本;

    • 会把每个组件定义成一个大的模块,然后在细化成具体的模块,比如大模块XXX-cache,子模块则叫XXX-cache-core、XXX-cache-service等;

    • 做开源二次开发的模块会单独定义成一个模块,比如配置中心扩展定义为XXX-config-file等;

    • 会把基础功能独立完成的单独作为一个模块比如叫XXX-db-mybatis、XXX-utils等;

    • 把其它公共的组件作为一个独立的模块,比如XXX-common;

    • 最后新建一个样例模块,用于验证基础框架;

    一个简单的框架模块就这样划分完成了,大概一看没什么毛病,可这其中的问题一大堆;我们看看正确的模块划分思路是怎么样的,首先我们得梳理清楚几个点;

    1、确定用户,开发的这个框架是给谁用的,如果给开发人员用需要支持哪些功能,如果是给测试人员用,需要支持哪些功能,如果是给业务开发人员使用,有需要支持哪些功能;

    2、框架怎么用,项目框架能不能灵活的解耦和组装,每个模块之间怎么交互,单元测试怎么做,代码怎么管理等;

    3、框架的量级规模,这个框架能支持多大的用户数,每秒请求数等等;我们需要根据数据规模,确定数据是否需要分片、分库,同时也要确定中间件的选择,能否满足当前场景;

    4、高性能,怎么提供集群方式,怎么扩容,怎么实现7*24小时不宕机,怎么实现灰度发布等功能;

    软件的复杂度和它的规模成指数关系。一个复杂度为100的软件系统,如果能拆成互不相关、同等规模的子系统,那么每个子系统的复杂度是25,而不是50。软件开发这个行业很久之前就形成一个共识,应该将复杂的软件系统进行拆分,拆分多个复杂度更低的子系统,子系统还可以拆分为更小粒度的组件。

    拆分的时候有哪些原则

    01

    组件内聚原则

    组件内聚原则主要讨论哪些类应该聚合在同一个组件,以便组件既能够提供相对完成的功能,又不至于太过庞大;

    02

    复用发布等同原则

    软件复用的最小粒度应该等同于其发布的最小粒度。也就是说,如果希望别人以怎样的粒度复用你的软件,你就应该怎么样的粒度发布你的软件。组件是软件复用和发布的最小粒度软件单元。这个粒度即是复用的粒度,也是发布的粒度。

    版本号约定建议:

    • 版本号格式:主版本号.次版本号.修订号。比如2.5.1,这个版本中,主版本号是2,次版本号是5,修订号是1;

    • 主版本号升级,表示组件发生了不向前兼容的重大修订;

    • 此版本号升级,表示组件进行了重要的功能修订或者bug修复,但是组件是向前兼容的;

    • 修订号升级,表示组件进行了不重要的功能修订或者bug修复。

    03

    共同封闭原则

    应该将同时修改,并且为了相同目的而修改的类放到同一个组件中。而将不会同时修改,并且不会为了相同的而修改的类放到不同的组件中。

    组件的目的虽然是为了复用,然而开发中常常引发问,恰恰在于组件本身的可维护性。如果组件在自己的生命周期中必须经历各种变更,那么最好不要设计其它组件,相关的变更都在同一组件。这样,发生变更的时候,只需要重新发布这个组件就可以了,而不是一大堆组件都受到牵连。

    04

    共同复用原则

    这个原则是说,不要强迫一个组件的用户依赖他们不需要的东西。

    一方面,我们应该将相互依赖、公共复用的类放在一个组件中。另一方面,这个原则也说明,如果不是被公共依赖的类,就不应该放在同一个组件中。如果不被依赖的类发生变更,就会引起组件变更,进而引起使用组件发生变更。这样就会导致组件的使用产生不必要的困扰,甚至讨厌使用这样的组件,也造成了复用的困难。

    05

    无循环依赖原则 

    组件依赖关系中不应该出现环。如果组件A依赖组件B,组件B依赖组件C,组件C又依赖组件A,就形成了循环依赖。

    很多时候,循环依赖在组件的变更中逐渐形成的,组件A版本1.0依赖组件B版本1.0,后来组件B升级到1.1,升级的某个功能依赖组件A的1.0版本,于是形成了循环依赖。如果组件的设计边界不清晰,组件开发的设计缺乏评审,开发者只关注自己开发的组件,整个项目对组件依赖管理没有统一的规则,很有可能出现循环依赖。

    06

    稳定依赖原则?

    组件依赖关系必须向更稳定的方向。很少有变更的组件是稳定的,也就是说,经常变更的组件是不稳定的。根据稳定的依赖原则,不稳定的组件应该依赖稳定的组件,而不是反过来。

    反过来说,如果一个组件被更多的组件依赖,那么它需要相对稳定的,因为想要变更一个被很多组件依赖的组件,本身就是一件困难的事。相对应的,如果一个组件依赖了很多的组件,那么它相对也是不稳定的,因为它依赖的任何组件变更,都可能导致自己的变更。

    07

    稳定抽象原则?

    一个组件的抽象化程度应该与其稳定性程度一致。也就是说,一个稳定的组件应该是抽象的,而不是稳定的组件应该是具体的。

    这个原则对具体开发的指导意义就是:如果你设计的组件是具体的、不稳定的,那么可以为这个组件对外提供服务的类设计一个接口,并把这组接口封装在一个专门的组件中,那么这个组件就相对比较抽象、稳定。

    设计的过程中应该遵循怎样的原则

    最著名的就是倒三角原则,在微服务的场景中特别重要,在架构设计的过程中最重要的就是Needs需求,首先要理解需求是什么,要解决什么问题?有了这个需要看看这个方案和架构能不能带来Values(价值),如果能带来价值,使用这种方案需要用什么Principles(原则),在原则之下我们要知道Practices(最佳实践)是那些,最好好这个架构技术选型需要那种Tools(工具),包括基础框架、设计等框架。

    有了这些基础原则的支撑我们是不是对模块设计又有了新的了解,没有最好的模块设计,只有符合公司业务需求模块的最佳实践。不能说这个框架满足什么需求,应该说这个需求被框架支撑着。所有很难出现一个基础框架满足所有需求,只能做各种适配,从而丢失了框架应该有的特性。

     

    展开全文
  • 微服务模块划分原则

    万次阅读 2019-06-22 21:46:10
    微服务架构作为目前使用的主流架构,已经被广泛使用,但是对于服务的划分却没有固定的原则,在工作中也经常会出现服务划分过度或者不充分的情况。所以在这里想探讨一下服务边界和服务划分的方法。 微服务设计四个...

        微服务架构作为目前使用的主流架构,已经被广泛使用,但是对于服务的划分却没有固定的原则,在工作中也经常会出现服务划分过度或者不充分的情况。所以在这里想探讨一下服务边界和服务划分的方法。

       微服务设计四个原则:

    • AKF拆分原则
    • AKF扩展立方体(参考《The Art of Scalability》),是一个叫AKF的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式,可以将一个单体系统,进行无限扩展。

      X 轴 :指的是水平复制,很好理解,就是讲单体系统多运行几个实例,做个集群加负载均衡的模式。

      Z 轴 :是基于类似的数据分区,比如一个互联网打车应用突然或了,用户量激增,集群模式撑不住了,那就按照用户请求的地区进行数据分区,北京、上海、四川等多建几个集群。

      Y 轴 :就是我们所说的微服务的拆分模式,就是基于不同的业务拆分。

      场景说明:比如打车应用,一个集群撑不住时,分了多个集群,后来用户激增还是不够用,经过分析发现是乘客和车主访问量很大,就将打车应用拆成了三个乘客服务、车主服务、支付服务。三个服务的业务特点各不相同,独立维护,各自都可以再次按需扩展。

    • 前后端分离

    前后端分离原则,简单来讲就是前端和后端的代码分离也就是技术上做分离,我们推荐的模式是最好直接采用物理分离的方式部署,进一步促使进行更彻底的分离

    • 无状态服务

    对于无状态服务,首先说一下什么是状态:如果一个数据需要被多个服务共享,才能完成一笔交易,那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务,反之称为无状态服务。

    那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态,表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务,那么状态数据也就相应的迁移到对应的“有状态数据服务”中。

    场景说明:例如我们以前在本地内存中建立的数据缓存、Session缓存,到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储,让业务服务变成一个无状态的计算节点。迁移后,就可以做到按需动态伸缩,微服务应用在运行时动态增删节点,就不再需要考虑缓存数据如何同步的问题。

    • Restful通信风格

    作为一个原则来讲本来应该是个“无状态通信原则”,在这里我们直接推荐一个实践优选的Restful 通信风格 

    微服务设计目标

    • 架构必须稳定;
    • 服务必须高内聚 - 服务应该实现一小组强相关的功能;
    • 服务必须符合开闭原则 - 将一同变更的内容打包在一起,以确保每个更改仅影响一个服务;
    • 服务必须松耦合 - 每个服务都可以在不影响客户端的情况下更改实现;
    • 服务应该是可测试的;
    • 每项服务都小到足以由“两个披萨”团队开发,即一个6-10人的团队;
    • 负责一个或多个服务的每个团队必须是自治的 - 团队能够在与其他团队尽量少的协作下,来开发和部署他们的服务。

    服务划分方法

    通过领域驱动设计(DDD),设计与 子域 相对应的服务。DDD通过分析问题空间和业务逻辑,将应用程序定义为域。域由多个子域组成。每个子域对应于业务的不同部分。

    子域可分为以下几类:

    • 核心类 - 业务的关键差异化因素和应用程序中最有价值的部分;
    • 支持类 - 与业务有关,但与差异化无关;这些可以在内部实施或外包;
    • 通用类 - 与业务无关,理想情况下可以使用现成的软件实现。

    例如一个会员账号管理系统包含以下几个子域:

        账号管理域:包含账号的模型和提供的基本接口能力

        登录模块域: 涉及登录和免登流程

        注册账号域: 账号注册和账号创建能力

        个人中心域: 涉及个人中心管理

    展开全文
  • 微服务划分原则

    2020-12-16 23:48:31
    确切地说,服务中⼼的划分原则更多的是架构设计经验总结,我们很 难对⼀些具体的问题给⼀个精确的量化指标,但有⼀点,我很反对现在微 服务中的LOC(Line Of Code)这种指标,即⽤代码的⾏数来衡量⼀个微服 务...

    确切地说,服务中⼼的划分原则更多的是架构设计经验总结,我们很难对⼀些具体的问题给⼀个精确的量化指标,但有⼀点,我很反对现在微服务中的LOC(Line Of Code)这种指标,即⽤代码的⾏数来衡量⼀个微服务落地的标准。架构本来就是⼀个追求平衡的艺术,不仅是设计原则上的平衡,还要在技术、成本、资源、性能、团队等各⽅⾯进⾏平衡,以最⾼效地解决主要问题。我认为这也是⼀名优秀架构师的必备特质,偏执地追求⼀个维度的完美肯定会在其他⽅⾯付出代价。从服务中⼼设计来看,⼀定要兼顾三个⽅⾯的需求,如图所⽰:

    如果不能兼得,就抓住需要解决的主要⽭盾。共享服务中⼼的架构⽬的是通过业务拆分来降低系统的复杂性;通过服务共享来提供可重⽤性;通过服务化来达到业务⽀持的敏捷性;通过统⼀的数据架构来消除数据交互的屏障。所以,所有的原则和⽅法都是为了这些⽬标服务的,“以终为始”再来看服务中⼼建设的原则和⽅法就会明确很多。

    从设计层⾯来看,主要是要遵循⾯向对象的分析和设计的⽅法,即业务和系统建模遵循⾯向对象的基本原则,这些是多年软件⼯程学的沉淀,服务化不是开创⼀套新的设计⽅法,⽽是⼀个指路的明灯。从运营层⾯来看,服务中⼼应该是⼀个完整的业务模型,要有数据运营和业务整合的价值,前⾯在介绍淘宝的服务中⼼时,⼀直在强调服务中⼼的发展变化性和可运营性,⽐如淘宝的商品中⼼,绝对不只是简单的商品增删改查的服务接⼝,⽽是建⽴⼀个全球最⼤的商品库,同时提供该商品库的管理运营的⽅法和配套⼯具服务。当然淘宝的商品中⼼建⽴成这样是淘宝的电商业务决定的,并不意味着其他业务系统也要按这样的标准去建⽴⾃⼰的商品中⼼,⼀切要根据业务来做判断。

    从⼯程层⾯来看,共享服务的架构是基于分布式架构,分布式架构解决了⼀体化架构在⼤规模应⽤上的问题,但是也引⼊了分布式事务、问题排查等⽅⾯的⼀些难题,所以在规划服务中⼼的时候,⼀定要综合评估业务层对服务中⼼在数据库、业务以及运营⽅⾯的需求和技术上需要的投⼊。不能图⼀时之快把业务拆得⾮常彻底,到最后却不得不⽤很⼤资源投⼊来解决技术上⾯对的问题。

    总体上,我们从这三个维度出发来决定服务中⼼的设计和评估。下⾯我们具体介绍在实际项⽬中总结的⼀些基本原则。

    1.⾼内聚、低耦合原则

    这是系统设计⼀开始就会强调的⼀个基本原则,不过很多时候在实践中我们都在不知不觉中就违背了这个原则。⾼内聚是从服务中⼼的业务界

    域来说的,在⼀个服务中⼼内的业务应该是相关性很⾼、依赖性很⾼的;⽽服务中⼼之间应该是业务隔离性⽐较⼤的,即追求尽可能的低耦合。注

    意这⾥的业务隔离性是从应⽤场景来说的。

    举⼀个例⼦,很多应⽤⼀般都有⼀个会员中⼼,在会员的业务中,会有⽤营销⼿段来保持会员的忠诚度和活跃度,有些⽤户会倾向于把积分独⽴出来建⽴⼀个独⽴的积分中⼼或者放到营销中⼼,有些⽤户会觉得积分直接放在会员中⼼和会员等级挂钩。这⾥如果是你的系统,你会选择怎么做?其实,从之前的项⽬实践来看,⼀般建议⽤户先不要独⽴积分中⼼出来,因为拆分出⼀个积分中⼼,意味着你把会员服务的粒度缩⼩了,但是你的积分业务还不⾜够丰富的时候其实就只剩下增、删、改查的服务需求,对这种服务中⼼,不建议⼀开始就独⽴出来⼀个服务中⼼,还是等积分相关业务发展到⾜够丰富的程度或者对其他业务中⼼影响已经不可忽略

    的时候再去拆分出来不迟。

    2.数据完整性原则

    这个原则其实和上⾯的“⾼内聚、低耦合”⼀脉相承,是把这个思想穿透到数据模型层⾯,因为服务化架构⼀个很重要的业务价值就是数据模型统⼀。这⾥特别想强调⼤数据的思维,不光只是业务逻辑的关键数据,还要考虑到业务的相关性数据;不光是实时在线数据,还要考虑到离线计算的数据。

    3.业务可运营性原则

    服务中⼼⾸先是从业务出发,单纯的技术层⾯抽象出来的服务框架⼀般不作为⼀个可运营的服务中⼼。单纯的技术型的服务中⼼可以存在,但不是这⾥讨论的重点,我们期望服务中⼼是承载业务逻辑、沉淀业务数据、产⽣业务价值的业务单元。业务的运营性有两个层⾯含义,⼀是指业务本⾝的活⼒,当业务处于快速⽣⻓期,这时候的运营⽬标是满⾜上层的业务需求,这个时候属于沉淀阶段;第⼆个层⾯的运营是指业务内部的孕育出来的创新想法,⽐如淘宝基于⼤数据分析技术⽣⻓起来的商品巡检技术、前台类⽬⾃动聚合推荐技术等。数据模型统⼀之后,可⽤很低成本把⼤数据技术引⼊到服务中⼼的架构中,让数据来源、数据分析、业务⽣产可以⾃然形成闭环。所以能否⽤⼤数据能⼒提升运营⽔平是服务中⼼原则之⼀。

    4.渐进性的建设原则

    渐进性的建设原则是从降低⻛险和实施难度这个⾓度出发,服务化架构本来就是⼀种敏捷的实践,我们是推荐⼩步快跑的⽅式逐步推进,不是轰轰烈烈地推翻重来。其实在分布式架构体系下,在企业互联⽹架构体系下,试错的成本已经降到⾜够低,渐进式的建设也是服务中⼼建设的⼀个重要原则。

    有些⼈会觉得服务中⼼是基础服务,应该是⾮常稳定的,所以⼀开始规划设计的时候应⽤了太多的设计原则,最后从设计上看的确很清晰,但是在实施阶段,可能会碰到拆得过细有延迟太⻓的问题,数据过于分散有数据库性能的问题和分布式事务的问题,服务接⼝过于庞⼤的问题。这些实践证明都不是好的服务化实践。我们推荐服务化从简单开始,只有真实的业务需求才会锤炼出稳定可靠的共享服务。

    展开全文
  • 微服务架构中模块划分和服务识别

    千次阅读 2017-12-14 16:42:04
    除了谈到微服务技术架构外,客户往往更加挂你微服务模块的划分粒度,已经具体的微服务API接口的识别和定义问题,因此这篇文章将重点谈下微服务架构实践过程中的微服务模块划分和服务识别。 最近在...

    微服务架构中模块划分和服务识别

    最近在进行微服务架构的交流和讨论中,除了谈到微服务技术架构外,客户往往更加挂你微服务模块的划分粒度,已经具体的微服务API接口的识别和定义问题,因此这篇文章将重点谈下微服务架构实践过程中的微服务模块划分和服务识别。



    最近在进行微服务架构的交流和讨论中,除了谈到微服务技术架构外,客户往往更加挂你微服务模块的划分粒度,已经具体的微服务API接口的识别和定义问题,因此这篇文章将重点谈下微服务架构实践过程中的微服务模块划分和服务识别。

    首先我们还是再总结在在跨系统间的接口集成中服务的识别和定义方法,可以总结为:

    1. 基于流程架构和业务架构,从跨系统交互流程出发,分析业务交互接口点,识别关键的业务服务能力。

    2. 基于数据架构和主数据建模分析,识别关键的数据服务能力。

    3. 基于技术架构和共性平台层技术组件的分析和定义,以能力开放原则识别关键技术服务能力。

    因此对于跨系统间的集成,对于服务识别和定义思路是相对清晰的。那么在传统方法中业务系统的划分和定义粒度又是如何?在前面企业架构分析中,我曾经谈到过,通过跨系统交互流程分析,识别出最细粒度的业务功能模块和功能单元,然后再从底向上进行聚合,以CRUD分析为主要方法,多次迭代出最佳的满足高内聚,松耦合条件的业务系统划分。这里面没有一个精确方法,但是却有该大原则下的指导方法。

    微服务模块的划分

    微服务模块的划分不是什么新鲜事物,就是传统的业务系统内部的业务功能组件的划分,但是我要注意到的关键一点还是业务组件本身的粒度和大小。原来没有完全拆分为独立的微服务模块的时候,我们一个业务系统可以划分20个以上的业务模块,因为由于数据库本身没有拆分,同时业务模块间的调用本身又是内部的API调用,因此感觉不到有什么问题。但是如果把这20个业务模块完全拆分为独立的微服务模块,你才会发现模块间的紧耦合或者说大量的交互集成接口,会导致整个系统集成和交互关系相对复杂,后期很难管理。

    这也是我们原来经常强调的,传统的一个大业务系统划分微服务模块的时候,尽量是划分到6到8个模块比较合适,当你本身的IT成熟度达到一定水平后你可以划分的更加细点。同时在微服务模块划分的时候一定要考虑数据库本身的划分,即底层的数据库也是划分开的,类似我原来谈私有云PaaS的时候谈的数据库的水平拆分。

    究竟如何拆?实际上方法仍然是一样的,还是要分析单个业务系统内部的流程,然后分解到具体的业务组件或功能,再按照高内聚的原则进行聚合,尽量确保各个微服务模块之间的交互最少。同时对于大家都要用到的基础数据模块,仍然采用共性下沉的策略和思路进行。同时一个有价值的参考方法是,分析该业务系统承载的主体业务流程是什么?然后分析这个业务流程可以横向划分微哪几个独立的阶段,然后先将这些独立的阶段划分微不同的微服务模块,在划分好后再进行CRUD分析进行修正。

    微服务接口的识别和定义

    不管是传统的跨业务系统间交互的接口,还是微服务模块间的交互API接口,我一直强调的一个关键就是接口一定要保证粗粒度特性,实现业务规则和逻辑的高度内聚。接口面对的应该是核心的业务对象,领域对象或业务规则能力暴露,而不是微服务模块内部的数据库表的CRUD操作的暴露。如果将数据库表CRUD操作暴露为Rest API接口并在微服务模块间相互调用。一个是耦合性增加,一个是完全没有实现高内聚的基本要求。

    基于以上基础原则,我们在进行微服务接口识别和定义的时候,仍然需要从业务流程出发,梳理清楚完成一个完整的业务流程各个微服务模块之间有哪些业务交互接口,然后将这些接口识别出来后,才进行接口的拆分或合并,最终形成微服务API接口,只有这样最终的微服务API接口才是可以复用的。

    由于我们已经将基础数据管理独立到一个基础模块,因此可以基于数据能力开放和暴露的原则将这些基础数据的能力以查询服务方式暴露为独立的数据服务能力接口。要求仍然是领域对象级而不是数据库表级别。

    每一个微服务模块在开发和实现的时候,如果都是基于领域驱动架构设计的思路进行的,那么只有微服务模块的领域对象定义完整,完全可以将领域对象的能力以API接口的方式暴露出去,这里既包括了查询类接口,也包括了导入或数据插入类接口,其次对于核心的业务规则的实现可以独立暴露为接口服务。

    在前面微服务架构咨询里面我曾经谈到过,在多个微服务模块之上,还可能有一个微服务能力组合层,实现类似流程服务和组合服务类的能力。如果存在这种情况,那么最好也是独立的微服务模块来实现,这个微服务模块本身可能并不对应具体的数据库,而是将底层的微服务模块之间服务能力进行组合,形成新的接口服务能力。

    由于在微服务架构设计中,我们更加强调数据不落地的方式进行后续的开发和实现,由于数据不落地,我们就可以更好的以能力开放的思路来进行接口的识别和暴露。简单来说有哪些数据或业务对象在你这,有哪些业务规则属于你管理?这些都在经过粗粒度聚合后,都可以识别和定位为微服务API接口。

    展开全文
  • 微服务是目前后端比较流行的架构体系了,那么如何做好一个微服务划分?一个微服务的粒度应该是多大呢?这篇主要介绍如何结合DDD进行领域划分。 工程结构代码 上篇介绍了可落地的DDD的(2)-为什么说MVC工程架构已经...
  • 微服务服务划分示例

    2020-04-02 14:00:20
    很多人在谈起微服务时,总是会很自豪的说,微服务为我们提供了高内聚低耦合的明显好处,因为微服务强化了模块化的概念。但是, 如何模块化,如何明确的定义模块的边界,却很少有人提及,而这正是微服务架构的难点,...
  • 微服务的设计原则

    千次阅读 2019-05-30 20:01:16
    一 前言 ...那么关于微服务的设计原则有哪些呢?如下: AKF 拆分原则 前后端分离原则 无状态服务 RestFul 的通信风格 二AKF 拆分原则 有句挺流行的话:没有什么事是一顿烧烤解决不了的,如果...
  • 微服务架构设计原则

    2018-06-05 10:23:37
    本文将介绍微服务架构的演进、优缺点和微服务应用的设计原则,然后着重介绍作为一个“微服务应用平台”需要提供哪些能力、解决哪些问题才能更好的支撑企业应用架构。微服务平台也是我目前正在参与的,还在研发过程中...
  • 作者:人月聊IT原文:https://www.toutiao.com/i6897541960978924043/概述对于传统企业微服务...而对于微服务整体的治理框架,我在前面给出一个大的框架图,如下:整个微服务治理框架覆盖了微服务全生命周期管理,...
  • 概述对于传统企业微服务架构转型,基于中台和微服务思想进行传统IT系统的改造和优化是一个重要的趋势,特别是在企业IT架构逐步走向云原生技术的...而在微服务架构规划阶段最重要的又是两件事情,即微服务模块的拆...
  • 拆分原则: 单一职责、服务粒度适中、考虑团队结构、以业务模型切入、演进式拆分、避免环形依赖和双向依赖拆分步骤: 分析业务模型、确定服务边界、模块拆分、数据库拆分...
  • 微服务拆分原则

    2021-01-15 17:22:32
    拆分的大原则是当一块业务不依赖或极少依赖其它服务,有独立的业务语义,为超过 2 个的其他服务或客户端提供数据,那么它就应该被拆分成一个独立的服务模块 单一职责、高内聚低耦合:简单来说一张表划分为一个服务...
  • 微服务划分的姿势

    2019-08-22 09:53:20
    我们知道微服务是一种理念,没有确切的定义和边界,好比设计原则,是属于抽象的概念。在定义不明确的情况下谈划分也是一种各说各话,具体问题需要具体分析,所以这篇文章谈到的划分也不是绝对标准,仅供参考。  ...
  • 1) AKF 拆分原则 2) 前后端分离原则 3) 无状态服务 4) RestFul 的通信风格 1 AKF 拆分原则 业界对于可扩展的系统架构设计有一个朴素的理念,就是: 通过加机器(水平扩展)就可以解决容量和可用性问题 。( 如果一台...
  • 微服务拆分微服务拆分时机为了快速迭代高并发场景可重用提交代码经常冲突小功能要积累到大版本才能上线服务拆分原则原则一:高内聚和低耦合。原则二:服务拆分正交性原则原则三:服务粒度适中、演进式拆分原则四:...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 7,129
精华内容 2,851
关键字:

微服务模块划分原则