精华内容
下载资源
问答
  • 业务系统拆分的基本思路

    千次阅读 2018-05-30 10:44:59
    1. 梳理所有的业务功能环节 粗粒度的拆,比如客户服务,订单服务...2. 选取某一业务,比如订单,从上至下的拆分,用思维导图金字塔的方式... 如果系统业务比较多,处理逻辑上有差异,可以将业务主体分为几类,...

    1. 梳理所有的业务功能环节

          粗粒度的拆,比如客户服务,订单服务...

    2. 选取某一业务,比如订单,从上至下的拆分,用思维导图金字塔的方式进行

         将服务的步骤理解清楚,比如 1. 校验  2.生成订单(接口方式、界面方式) 3.服务开通 4.订单归档      

    3. 梳理所有业务主体,进行归类,画出业务泳道图。

        如果系统的业务比较多,处理逻辑上有差异,可以将业务主体分为几类,比如,普通业务,短流程业务,长流程业务,特殊业务等

    4. 将金字塔结构图结合业务泳道图通过关键指标来识别关键业务功能

        (1) 将所有的通过用业务逻辑组成公共服务,比如配置服务,调度服务,缓存服务等

        (2) 有一个业务主体,得到了各方面的关注,那么就把这个业务首先拆分出来独立成一个呜呜

        (3) 长流程业务就符合业务主体特殊一条标准,可以提取为一个独立的服务

        (4) 分渠道,比如将接口调用的逻辑和界面方式的逻辑解耦成两个服务,比如后台和接口,使得两个变成独立的管道互不影响

    5. 进行重构

        重构手法:

        (1) 因为业务量特别大,系统采用消息队列的方式进行处理,通过接骨法接触代码之间的耦合,并提供对外服务的借口

        (2) 首先拆除所有的公共服务(校验服务,规则服务,开通服务,归档服务),然后再拆分特殊业务主体服务(重点业务,长流程业务),最后拆不同驱动实现方式(接口服务和界面服务)

        (3) 比如创建订单的环节,设计所有的业务主体,影响大,所以这个服务不能一下子全拆出来,要通过修路法,先建设一个订单服务和原来的系统并行使用,同时分流出几个试点业务到订单服务。当上下游调用没有问题,可以正常创建订单后,再通过分批逃跑法,逐步地将其他业务的处理迁移到这个微服务上面,最终当所有的业务都迁移成功之后,原来的系统的订单处理逻辑就废弃了。

        (4) 在这些业务的拆分过程中,数据库拆分的工作也同时进行


    展开全文
  • 1.通过系统业务拆分,遵循单一职责原则SRP,保障整个系统的可用性和稳定性。 2.单一职责原则SRP,真的很关键,广大程序员需要不断深入理解这个原则。 3.架构图是架构师的重要输出,通过图可以直观地看出整个架构...

     

    个人观察

    1.通过系统和业务拆分,遵循单一职责原则SRP,保障整个系统的可用性和稳定性。

    2.单一职责原则SRP,真的很关键,广大程序员需要不断深入理解这个原则。

    3.架构图是架构师的重要输出,通过图可以直观地看出整个架构思路。

     

     

     

     

    本文转载于

    《程序员》2014年11月刊:电商峰值系统架构设计

    原文链接:http://www.csdn.net/article/2014-11-04/2822459

     

     

    该做什么的就做什么

    保障整个系统的可用性和稳定性,第一步需要做 的就是,使整体架构清晰化、层次化。那么,对系统进行合理拆分,是最直观的选择。从业务和技术角度出发,遵循SRP(Single Responsibility Principle)原则,合理拆分系统中的各个模块,明确每个模块的职责。这样可以方便快速定位和排查问题,甚至可以有针对性地对每个模块进行优化。

    拆分方式基本上分为两种,路由拆分和物理拆 分。所谓路由拆分,就是按照请求特征,将请求流量分摊到两个或多个同质的集群里面;而物理拆分,就是在路由拆分的基础上,按照业务和技术上的特征,将同质的集群进行彻底拆分,成为非同质集群。

    下面以交易流程为例,来看一下如何操作拆分。

    交易流程主要包括购物车、下单、支付等几个环节,具体的拆分结果,如图1所示。

    图1  交易流程拆分结果 

    经过分析,整个交易流程按照架构层次可以分解为展示层、业务层及外围应用三块内容,这三部分由于职责差异比较大,所以先按照物理拆分,让层次清晰。

    再来看展示层,由于存在一些共享的东西,如页面元素等,做物理拆分,会引入额外的成本,所以路由拆分是不错的选择。

    接着来看业务层。这一层是很容易按照角色和业务场景进行拆分的,例如,交易管理服务是给管理人员提供管理功能的,需要考虑权限、内控等问题;交易核心服务是给业务主流程提供主要业务功能,需要考虑可用性;交易查询服务是读取交易数据的主要途径,需要考虑易用性;交易网关服务主要是对接外部支付渠道,需要考虑连通性。很明显,这一层由于自身的差异性比较大,所以采用物理拆分是上上策。

    最后来看外围应用,其中包括后台管理、日志查 询、业务监控及交易超时控制等,这些应用基本上都是在底层系统平台(管理平台、日志平台、监 控平台以及任务平台)进行二次开发而成的,所以天生就适合进行物理拆分。

    从上面不难看出,拆分是一个细活,可以选择的 维度很多,拆分方式也比较讲究。良好的拆分方案,会让系统更加清晰明了,每个模块该做什么的就做什么。这样应对大型促销活动时,可以游刃有余地按照模块特征进行优化。

     

    总结一下在可用性和稳定性工作中的一些感悟。 

    首先,清晰的架构划分可以大大减轻稳定性工作量;

    其次,功夫要尽量在平时做足,避免总是出临时解决方案;

    再次,普及稳定性思维,注意细节;

    最后,出现问题,先快速恢复再查找根源。  

     

    展开全文
  • 业务拆分的思考

    2018-09-21 20:19:00
    从最初的单体应用,即将进行业务拆分,分而治之,虽心不免有些激动,但是很快就陷入深思。 因为我不得不考虑如何拆分比较好及其现在要不要拆分的问题。 目前我们开发的是一个多租户系统应用,考虑到公共通用功能,...

    从最初的单体应用,即将进行业务拆分,分而治之,虽心不免有些激动,但是很快就陷入深思。

    因为我不得不考虑如何拆分比较好及其现在要不要拆分的问题。

    目前我们开发的是一个多租户系统应用,考虑到公共通用功能,例如用户功能、组织功能、菜单功能、模块功能、系统监控、审批功能、权限管理等,我们将其作为公共模块,而像共享方面的系统或者是智能门锁方面的系统,我们决定将其抽象另外的模块,当特定的用户需要该功能时,只需与我方沟通签订对应的合作协议,我方后台超级管理员只需配置下相应的权限即可。

    一、先谈谈是否要拆分的问题

    孙子曰:“不尽知用兵之害者,则不能尽知用兵之利“。

     

    还是回到之前的那个问题,业务是否真正需要拆分呢?这里要结合具体的业务需求。

    比如,目前我对这个多租户系统有这么样一个想法,如果要拆分,按照上述的原则公共模块进行抽取,抽取为一个后台web应用。

    而像共享方面(例如共享汽车等)和智能门锁可单独作为另外的一个应用。之所以这么做的原因在于处于如下考虑:

    (1)解耦性和可维护性

    如果所有的系统都要放入一个庞大的war下,那么代码耦合度可能会比较高,而且不易维护,就好比git分支开发,之所以强调每个人在自己的分支下开发对应的功能模块,是因为避免全部都在主分支开发时,导致出现的代码混乱和冲突问题。另外还有一个考虑是,通常主分支,也就是master分支,一般情况下,主分支的代码是不存在问题的,或者问题非常小,但是由于都在主分支上进行开发,导致有的时候,因为没有严格的代码审核机制,导致有些开发人员,比如曾经的我,仅仅只是为了完成任务而开发,写程序时,很少思考不考虑到是否会不会影响到其他同事的代码,最后的结果是,陷入的一个死循环,改bug,改bug....

    之所以强调可维护性,是因为,对于这个多租户而言,后台模块单独作为一个应用,由部分人负责,而像智能门锁或者是共享汽车等应用是另外一个模块,也由专门的开发人员负责,这样一来,你打你的我打我的,总的原则,坚持一个,“高内聚,低耦合,代码可读性良好,可扩展性良好”。

    当然了,实际情况也不能你打你的,我打我的,各自为战,该及时沟通还是得及时沟通,对于项目组长而言就需要时刻了解自己的组员工作进度及其代码方面的情况,因为这样一来当项目经理问起时,也不必胆战心惊。

    作为项目经理,处于整个项目的领路人,项目的成败,很大程度不仅仅是由底层的开发人员所决定,还有就是项目经理的决策和管理。

     

    (2)稳定性

    有这么一句话,“鸡蛋不能同时放在一个笼子下”。

    后台应用,一般情况下仅仅只是管理人员使用,或者是管理员通过权限分配指定某一些人使用。这样一来,基本上,不用考虑高并发。

    而像智能门锁这样的,不得不考虑高并发和性能方面的问题,如果全部将其放在一个war下,一个出问题,全部出问题,将会导致宕机,影响项目的正常服务,容错性差。

    这样看来,业务拆分,也是为了提高稳定性。

     

     

    二、谈谈业务拆分的思路

    (1)梳理所有的业务功能环节

    主要以粗分为主,例如智能门锁系统的智能门锁、智能网关等等这样的。

    (2)业务功能细分

    例如智能门锁系统中的智能门锁,它不仅包含门锁列表展示、安装门锁、门锁详情信息、门锁授权人、一次性密码和系统密码等,还包括如何开锁等等。

    (3)梳理业务主体,进行分门别类划分

    这里主要强调的是将业务分类,类似开发中的紧急并非常重要、紧急但不重要这样的开发优先级。

    (4)将金字塔结构图结合业务泳道图通过关键指标来识别关键业务功能

    也许这句话不是特别好理解,比较官方,不过当我说完后,你一定会非常明白。

    其实整个项目就是一个金字塔结构

    从顶层到下层,自顶向下,如图(画的有点丑,大家凑合着看吧)

     

     

     根据这幅图可归纳为如下四点:

    a. 将所有的通过用业务逻辑组成公共服务,比如配置服务,调度服务,缓存服务等;

    b.如果有一个业务主体,得到了各方面的关注,那么就把这个业务首先拆分出来独立成一个模块;

    c.长流程业务就符合业务主体特殊一条标准,可以提取为一个独立的服务;

    d. 分渠道,比如将接口调用的逻辑和界面方式的逻辑解耦成两个服务,比如后台和接口,使得两个变成独立的管道互不影响;

     

    (6)重构
    拆分的过程也意味着对代码进行重构。

    a.首先拆除所有的公共服务(校验服务,规则服务,开通服务,归档服务),然后再拆分特殊业务主体服务(重点业务,长流程业务),最后拆不同驱动实现方式(接口服务和界面服务);

    b.因为业务量特别大,系统采用消息队列的方式进行处理,通过接骨法接触代码之间的耦合,并提供对外服务的接口;

    c. 比如创建订单的环节,设计所有的业务主体,影响大,所以这个服务不能一下子全拆出来,要通过修路法,先建设一个订单服务和原来的系统并行使用,同时分流出几个试点业务到订单服务。当上下游调用没有问题,可以正常创建订单后,再通过分批逃跑法,逐步地将其他业务的处理迁移到这个微服务上面,最终当所有的业务都迁移成功之后,原来的系统的订单处理逻辑就废弃了;

    d.业务的拆分过程中,数据库拆分的工作也同时进行(主从和读写分离);

     

    三、分布式拆分

    提到分布式,普及下什么是分布式系统,这里我引用图片:

    引用百度百科:

    分布式系统(distributed system)是建立在网络之上的软件系统。正是因为软件的特性,所以分布式系统具有高度的内聚性和透明性。因此,网络和分布式系统之间的区别更多的在于高层软件(特别是操作系统),而不是硬件。内聚性是指每一个数据库分布节点高度自治,有本地的数据库管理系统。透明性是指每一个数据库分布节点对用户的应用来说都是透明的,看不出是本地还是远程。在分布式数据库系统中,用户感觉不到数据是分布的,即用户不须知道关系是否分割、有无副本、数据存于哪个站点以及事务在哪个站点上执行等。

     

    关于分布式拆分,我主要围绕三个方面讲,需求,原则,方法等三个方面。

    (1)需求

    a.组织结构变化

    从最初的一个团队逐渐成长并拆分为几个团队,团队按照业务线不同进行划分,为了减少各个业务系统和代码间的关联和耦合,几个团队不再可能共同向一个代码库中提交代码,必须对原有系统进行拆分,以减少团队间的干扰。

     

    b.安全

    这里所指的安全不是系统级别的安全,而是指代码或成果的安全,尤其是对于很多具有核心算法的系统,为了代码不被泄露,需要对相关系统进行模块化拆分,隔离核心功能,保护知识产权。

     

    c.替换性

    有些产品为了提供差异化的服务,需要产品具有可定制功能,根据用户的选择自由组合为一个完整的系统,比如一些模块,免费用户使用的功能与收费用户使用的功能肯定是不一样的,这就需要这些模块具有替换性,判断是免费用户还是收费用户使用不同的模块组装,这也需要对系统进行模块化拆分。

     

    d.交互速度

    单体程序最大的问题在于系统错综复杂,牵一发而动全身,也许一个小的改动就造成很多功能没办法正常工作,极大的降低了软件的交付速度,因为每次改动都需要大量的回归测试确保每个模块都能正确工作,因为我们不清楚改动会影响到什么,所以需要做大量重复工作,增加了测试成本。这时候就需要对系统进行拆分,理清各个功能间的关系并解耦。

     

    e.技术需求

    单体程序由于技术栈固定,尤其的是比较庞大的系统,不能很方便的进行技术升级,或者说对引入新技术或框架等处于封闭状态;每种语言都有自己的特点,单体程序没有办法享受到其它语言带来的便利;对应到团队中,团队技术相对比较单一。

    相比于基于业务的垂直拆分,基于技术的横向拆分也很重要,使用数据访问层可以很好的隐藏对数据库的直接访问、减少数据库连接数、增加数据使用效率等;横向拆分可以极大的提高各个层级模块的重用性。

    f.业务需求

    由于业务上的某些特殊要求,比如对某个功能或模块的高可用性、高性能、可伸缩性等的要求,虽然也可以将单体整体部署到分布式环境中实现高可用、高性能等,但是从系统维护的角度来考虑,每次改动都要重新部署所有节点,显然会增加很多潜在的风险和不确定定性因素,所以有时候不得不选择将那些有特殊要求的功能从系统中抽取出来,独立部署和扩展。

     

    (2)原则

    a.业务优先

    每个系统天然都会按业务功能分成多个模块,每个模块又包含许多业务相关的功能,在系统拆分时,我们就可以优先考虑按照业务边界进行切割,切割完成后再针对每个模块进行拆解,循序渐进,逐渐迭代深入,最终完成系统的拆解。这个过程类似庖丁解牛,要找到关节之处下刀,方能事半功倍。

     

    b.循环渐进

    系统拆分过程中包含两个非常重要的工作:拆分和测试。二者缺一不可,并且二者是并行进行的,一定要边拆分边测试。每一步拆分完成都要保证系统功能是完整的,保证系统的测试是完整的。拆分要小步前进,如此以来可以减少累计错误的发生。这一点在《重构》这本书中也讲到了。

     

    c.兼顾技术

    系统不能为了分布式而分布式,系统拆分的代价相当昂贵;当然如果有拆分的需要,我们也不能白白浪费这么好的学习机会:

    可靠测试:“重构之前,首先检查自己是否有一套可靠的测试机制”,这是MartinFowler在《重构》这本书中说到的,它同样对系统拆分有效。拆分是在对系统进行大手术,每一次的改动都要保证系统保持原来的行为不变。测试使得我有足够的信心进行下一步的拆分或重构,不至于在错误的道路上越走越远,以至于错误累积。测试与拆分如影随形,每一步都要有足够的测试。没有测试的拆分和重构我真的不敢想象结果会是什么样子。

    关于测试的重要性可以参考我的这篇文章:论单元测试之重要性

    之前我强调过,测试由底层的单元到高层的UI,其中单元是最有利于发现问题解决问题的。

     

    (3)方法

    a.公共模块复用;

    b.增加代理,解耦;

     

    小结:

    本文主要讲三个大方面,第一个是业务拆分是否有必要拆分;第二个是业务拆分的思路;最后一个是分布式业务拆分。

    本文的重点在于第一个和第二个,因为这两个我深有体会,试验过,应用过。至于分布式的话,此次主要普及下相关的知识和给有这方面需求的人启发。

    本文主要参考如下两篇文章:

    业务系统拆分的基本思路:https://blog.csdn.net/u011402896/article/details/80506394

    分布式拆分:https://blog.csdn.net/zzz34k/article/details/52576731

    当然了,也加上了我自己的理解和想法。

    希望能给广大的IT友友们带来有益的收获。

    展开全文
  • 系统拆分原则

    千次阅读 2015-08-08 21:15:42
    细数到今天,拆分系统已经断断续续进行了一个月了,希望在这里整理一下,对接下来的拆分工作有益。 这里记录一下在实际工作中总结的几条原则吧,主要是达到各系统间低耦合,系统内部高内聚。 1. db不能跨系统访问。...

    细数到今天,拆分系统已经断断续续进行了一个月了,希望在这里整理一下,对接下来的拆分工作有益。

    这里记录一下在实际工作中总结的几条原则吧,主要是达到各系统间低耦合,系统内部高内聚。

    1. db不能跨系统访问。自己的db自己管理,简单好维护,降低各系统间的数据耦合度。需要做成这样很多以前的联合查询都得改造。
    1. 各子系统要封装得足够好。所有子系统通过自己的api项目向其它子系统提供数据服务,这些api项目打包成jar包供其它子系统使用,以降低业务耦合性。
    1. 子系统不缓存其它子系统的数据。因为只要缓存其它子系统的数据就可能会造成数据不一致,但是这样严格做起来有一定的难度(系统间调用耗时)。所以有的时候为了性能考虑会缓存少量关键数据。比如说一个用户小李注册后,他的基本信息存在用户系统。他又申请成为了特约投稿人,那他特约投稿人的信息就存在投稿系统。如果业务系统有很多对用户不同身份而进行不同的操作,就可以把小李是特约投稿人的身份存在用户系统里,而不用每次都到投稿系统查询。
    1.  缓存距离用户越近越好。顾名思义就是将变动比较少的数据缓存放到http服务器上,这样可以达到最快的响应。变动比较大的数据在前端用js来请求并渲染,充分利用浏览器的性能来提高用户体验,分担服务器的压力。
    1. 如果数据必须不能丢失,拉比推更安全。首先拉有序列,只要有序列就可以通过记录最后一条回执来保证之前的都已获取,而不用像推送那样来记录每一条记录的回执;其次,推送需要有回执才能证明对方已经接收到,如果拉的话由自己来记录自己拿到第几条,不需要有回执这一步了。


    先写这些吧,以后发现再补充。

    展开全文
  • 个人对系统拆分的理解

    千次阅读 2018-07-18 14:25:41
    在本人现在的公司和本人工作过的上一家公司,本人有幸参与并实施了公司业务系统的架构拆分,现将之前的工作总结下。 1,为什么要进行系统拆分 首先我们需要想想,到底什么样的系统需要进行拆分?并不是所有的系统...
  • 之前文章中我们介绍了如何使用MyCat进行读写分离,类似的关系型数据库的读写分离存储方案可以在保持上层业务系统透明度的基础上满足70%业务系统的数据承载规模要求和性能要求。但是这个方案也有一个明显的问题,那...
  • 系统设计的垂直拆分和分平拆分

    千次阅读 2018-04-20 15:34:12
    系统将会变的越来越庞大,也会逐渐拆分成各个子系统来支撑,这此就需要把系统拆分,把原来强耦合的系统拆分成弱耦合的多个子系统,数据表也因为数据量大,需要按业务垂直拆分和按大小来水平拆分。 2 系统的拆...
  • 分布式架构之系统拆分

    万次阅读 2016-09-18 18:26:42
    系统拆分是单体程序向分布式系统演变的关键一步,也是很重要的一步,拆分的好坏直接关系到未来系统的扩展性、可维护性和可伸缩性等,拆分工作不难理解,但是如何正确拆分、有什么样的方法和原则能帮助我们拆分得到一...
  • 业务因素:服务拆分时先从业务角度确定拆分的方案,边界要充分考虑业务的独立性和专业性,按服务的业务功能合理的划出拆分边界,所有技术方面的考虑包括架构设计和解耦拆分都要考虑业务的需要。 投入产出比:拆分的...
  • 系统架构-性能篇章2(系统拆分1)

    千次阅读 2011-09-30 21:25:16
    系统为什么拆分系统做大了,并发量无法扛得住,如何做? 业务做复杂了,单个应用中不能个性化,如何做?...由 全世界用一个系统表达全世界所有的企业和公司的业务开始,注定系统做大后必然拆分的走
  • 分布式架构系统拆分原则、需求、微服务拆分步骤 为什么需要应用拆分 我以淘宝技术架构演进为例,淘宝从一个大系统工程向分布式架构演变过程,你就能很清楚的知道为什么要需要进行应用拆分。 1人员的角度。 ...
  • 一个复杂系统拆分改造实践

    千次阅读 2017-01-03 17:59:31
    1 为什么要拆分?...这种情况多存在于历史较长的系统,因各种原因,系统内的各个应用都形成了自己的业务小闭环; 2) 业务扩展性差。数据模型从设计之初就只支持某一类的业务,来了新类型的业务后又
  • 浅谈系统拆分

    2013-09-24 10:53:08
    今晚好冷啊,回去的路上,我突然想到一件关于系统拆分的事情。举的例子很极端,仅供参考,不一定有实际的意义 我感觉拆分系统,和拆分代码,本质上是一样的。小到一个方法,大到几个系统,都是一个从输入到输出的...
  • 架构设计:系统存储(13)——MySQL横向拆分业务透明化(1) 》 4-6、主要分片规则 上文提到MyCat的逻辑表支持多种分片规则,表现于schema配置文件中中table标签的rule属性。本节将以MyCat Version 1.6版为...
  • 我以淘宝技术架构演进为例,淘宝从一个大系统工程向分布式架构演变过程,你就能很清楚的知道为什么要需要进行应用拆分。 1 人员的角度。 维护一个代名工程Denali的百万级代码怪兽(虽然物理部署是分离的),从发布到...
  • 复杂业务流程的分析与拆分

    千次阅读 2018-10-12 13:43:29
    如果系统各个模块还没有拆分,这时对于一些很复杂的业务,其中任何一个业务流程可能会多次操作数据库,尤其是当业务流程中多次出现update 或者insert的时候,如果事务处理不好就会影响性能。以下针对我们业务系统中...
  • 前言:创业公司往往因为有限的时间和投入,把系统所有的功能都聚集在一起。随着业务的不断发展,技术人员开始不断...这里我想谈谈系统拆分需要考虑的因素和坚持的原则。业务因素所有技术方面的考虑,包括架构设计和解耦
  • 在文章《系统架构-性能篇章2(系统拆分1)》有提及到过关于系统在什么情况下会拆分拆分的目之类的问题,本文会阐述一些关于拆分过程中遇到的各种各样的常见问题进行分析,和上一个文章中提及到的一样,讲解的目录...
  • 系统架构设计模块拆分维度和原则

    千次阅读 2017-07-07 19:24:14
    在我们从零开始做一个新系统的时候,会首先进行系统功能模块架构设计,那么是直接做一个大而全的垂直的MVC系统,使用一个war包进行发布管理,还是需要按一些规则进行模块拆分,设计成SOA或者微服务系统比较好呢?...
  • 为什么要进行系统拆分? 如何进行系统拆分拆分后不用dubbo可以吗? 2 考点分析 从该节开始就进行分布式系统环节了,好多同学说,现在出去分布式成标配了,没有哪个公司不问问你分布式的事儿。你要是不会...
  • 在做微服务设计的时候,很大的一个难题就是服务的拆分,很多人都不知道在什么情况拆分服务,在什么情况下不应该拆分服务,所以设计的系统可能会很臃肿,如果遇到业务扩展,之前设计的架构不能满足业务扩增后的需求,...
  • 数据库拆分

    千次阅读 2011-10-15 20:18:52
    1 数据库拆分的兴起 在过去几年中,随着商业应用数据库事务量的大幅增长和数据库体积的增大,数据库拆分的概念已日益普及。许多在线服务供应商,软件即服务供应商(SaaS)和社交网站的成功更说明了这一点。 ...
  • 垂直拆分和水平拆分

    万次阅读 2017-07-15 22:22:09
    垂直拆分就是要把表按模块划分到不同数据库表中(当然原则还是不破坏第三范式),这种拆分在大型网站的演变...其实,相对于垂直切分更进一步的是服务化改造,说得简单就是要把原来强耦合的系统拆分成多个弱耦合的服务

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 74,670
精华内容 29,868
关键字:

系统业务拆分考虑