软件产品架构是不断迭代演化的，从单体服务架构发展到现在的服务化、微服务的架构。

单体架构

单体架构就是所有的业务模块都是耦合在一个项目中，开发、部署都在一起；如果其中一个模块需要上线升级，那么所有模块都要一起启停；

在早期，单体架构的项目团队成员需要是“全栈”，因为前端、后端、数据库都是一波人负责，后来开始进行了逻辑分层，团队也分成了前端 UI 团队、后端和 DBA 团队，每个团队都有自己负责的职责。

然而随着业务逻辑越来越复杂，模块和模块之间的耦合度越来越高；另外随着用户和数据量的增多，单体架构也不再能够支撑高并发和大数据。

SOA 架构

为了解决上面的问题，SOA 出现了。

SOA 代表了面向服务的架构，SOA 将应用程序的业务模块进行拆分，形成独立的应用系统，系统和系统之间通过明确的接口串联起来；

每个系统内部结构和逻辑发生改变，并不影响对外提供的服务，只要保持接口不变，服务内部对外是透明的；

SOA 架构中，服务定义标注的接口，可以提供给多个调用方使用，增加了服务的重用性。

SOA 架构时代有两个很重要技术实现方式：Web Service 和 ESB ：前者提供了标准的数据传输协议，后者实现了服务编排和协议转换。

微服务架构

但是随着用户和数据量的进一步增长，SOA 也暴露出来一些缺点，比如 SOAP 协议、XML较重；服务管理不完善；ESB本身就比较重，而且它本身算是一个单点，在软件架构中，单点意味着风险。

在微服务的架构中，各个微服务可以独立开发，独立部署；微服务之间通常使用Restful风格的API通信，传输格式也通常选择JSON；

微服务是SOA架构的延续，它们和单体应用相比，大大提高了系统的负载能力，解决了应用高并发的需求；

服务和服务之间的耦合度也被降低，并且项目团队可以被拆分成多个小团队，每个微服务都可以进行敏捷开发部署；

每个团队的技术栈也可以不相同，只要遵守接口协议即可。

至于微服务和 SOA 架构的区别，我是这样理解的：SOA 架构和微服务架构都属于分布式架构，分布式的思想就是把不同的业务模块，部署在不同的服务器上，以应对高并发的问题；SOA 是一种分布式架构，把业务系统分成多个子系统，提供不同的服务，再通过服务组合、编排实现业务流程；微服务是SOA的升华，如果非要说点儿不同的，那么微服务更加强调服务的细分和专业，去ESB总线、去中心化，部署粒度更细，服务扩展更灵活。

当然SOA、微服务的出现，在解决一些问题的时候，也带来了另外一部分的问题，比如增加了网络开销、服务依赖性、增加了测试运维难度、数据一致性问题等等。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

面对微服务如火如荼的发展，很多人都在了解，学习希望能在自己的项目中帮得上忙，当你对微服务的庐山真面目有所了解后，接下来就是说服自己了，到底如何评估微服务，什么时候使用微服务，什么时间点最合适，需要哪些技术储备和资源投入等等，这些都是你需要面对和解决的。

本文从单体架构，微服务架构，微服务风险评估，微服务落地条件等几个方面探讨微服务的落地过程，希望对你有所启发。

　　讲解微服务之前，我们先简单了解下单体架构。

一、单体架构

单体架构的优点：

• 快速开发和验证想法，证明产品思路是否可行

• 投入资源和成本，包括人力和物力相对比较节约

单体架构的缺点：

　　随着业务的复杂度增加，单体的灵活度会逐渐下降，比如：

• IDE过载：随着代码量增加，代码整体编译效率下降。

• 规模化：无法满足团队规模化高效开发。

• 系统开发、测试、部署的冲突和效率低下等问题

• 只能关注一套技术栈

• 应用扩展性比较差

• 海量用户高并发访问数量有限

单体适用场景：

　　架构设计的三大原则告诉我们，架构需要的是简单、适度、演化。

　　对于项目起步阶段，单体是最高效也是最节省成本的方式。因为初期阶段，由于人力，成本，业务熟悉程度，微服务技术积累等因素，如何过度设计可能工期和复杂度会急剧上升，造成交付困难，问题百出，从而错过了时间窗口。最合适，简单的方式还是单体优先，这是创业公司的特点决定的。当然设计面向微服务的单体架构也是一种聪明的方法，这遵守了系统演化的法则。

单体分层目的：

　　无论采取何种维度的架构分层，分层的最核心目的是保证各层之间的差异足够清晰，边界足够明显，为将来可能产生的变化提供最容易、最小化的修改。比如客户端要从安卓替换为IOS，底层无须任何改动，就像替换积木一样。又比如，设备需要接入新的设备或协议，其他层也不需要做任何变化，可以无缝平滑接入任何设备。

建议

　　如果前期在业务不十分清晰，求的是验证想法，证明产品思路是否可行性，并且业务量不大，仅限于省级范围，建议只要对当前架构稍加改良升级就可以了，这样改动量相对较小，且至少能支撑一定时间段的业务增长。

二、微服务架构

微服务的优势

　　支撑的业务更加庞大，可以支撑海量用户高并发和海量设备接入，支持分布式多机房，多区域部署，支持服务器无限扩容。支持私有云，公有云，混合云等部署方式。所以微服务是大多数互联网公司的首选。

微服务的代价

• 技术门槛高：微服务包括，服务描述，注册中心，服务框架，服务监控，服务追踪，服务治理等几大基本组件，以上每个组件缺一不可，每个组件展开又包括很多技术门槛，比如，容器技术，持续部署，DevOps等相关概念。
• 复杂性增加：相对单体架构将所有功能打包部署在一起，集中地进行开发、测试和运维，微服务会将这些单体的服务进行拆分部署，业务拆分粒度是一个难点，拆分后服务聚合也是一个麻烦。因为服务粒度增加后，相互调用，相互依存，所以问题排查难度会增加，就需要一套完整的服务监控，服务跟踪和治理的系统。
• 观念变化：微服务不仅仅是技术的升级，更是开发方式、组织架构、开发观念的转变。
• 前期投入成本较高

微服务架构图

　　微服务架构图谱谷歌或Bing下，可以看到各种各样的架构图，源于业务和架构师自身的喜好或者粗细粒度，但是每个架构图的基本组件和架构分层都差别不大，只是有的细一些，有的粗一下。比如有客户端层，容器层(K8S)，API Gateway，微服务集群层，EventBus层是必须要有的，至于服务监控和服务跟踪、服务治理本身就是一个完整的系统，粒度就没有细了。基于这些概念，我把架构图稍微细化一下，这里省去服务监控跟踪和治理的部分，后续多带带抽离出来分析。

　　这边的架构图谱相对之前的架构图，更加贴近业务，粒度也更细，虽然个别组件有所省略，比如跟踪和治理部分。

　　以上架构图主要分4层，每个层次遵循架构分层的核心思想：关注点分离，职责各异，边界清晰。

　　第1层：客户端：理论上包含一切可以联网的设备，包括移动设备，Android、IoS、Pad、微信、微博、QQ、Web、各自浏览器、物联网设备等等……

　　第2层：API网关：包括服务注册，发现，认证授权，单点登录，熔断，限流……网关的知识点丰富，是微服务的核心之一。

• 假如网关对外提供统一的地址：www.jackyfei.com

　　第3层：微服务集群：包括各种具体的microservice，比如纵向划分的业务服务(用户服务，订单服务，……)，横向划分的基础或公共服务(元数据服务，公共服务……)

　　其他微服务的地址可能是这样的：

• 用户服务：1.user.jackyfei.com订单服务：2.order.jackyfei.com元数据服务：3.base.jackyfei.com消息服务：4.msg.jackyfei.com

　　第4层：事件总线：Event Bus 目的是消息解耦，不要让服务之间直接的链接。不同与SOA的服务总线，事件总线相对比较轻量，经常基于消息队列引擎进行解耦，目的是为了让服务之间的关联弱化，不直接进行关联。很多时候用的是相对稳定、可靠、企业级的RabbitMQ。

　　微服务的架构其实不难，根据以上的架构，每种业务都可以进行套用，这里的难点在于服务的划分和粒度控制，另外如何管理膨胀的服务是一个麻烦事。

三、何时采用微服务?

3.1杨波说

　　这里引用架构师杨波(前Ebay架构师，目前任职拍拍贷研发部总监，资深技术架构师，微服务技术专家)的一些观点：

　　“企业一开始不推荐直接使用微服务，因为微服务需要前期基础设施的投资，复杂性很高，如果对问题领域并不是很理解，一开始用微服务，你很难去划分服务的边界，你的生产力反而会比较低，而且你花了很大精力进行开发，你的产品并没有被市场验证过，有可能会失败，所以这个选项风险会比较高。所以我们推荐的是单块优先，先从单块运用做起，这样成本低，团队成员也比较少，无须太多研发投入，就可以交付一些基本的功能给客户使用。

　　随着应用越来越成功，客户增加，你的系统复杂度会越来越高，就会出现单块应用和团队规模之间的矛盾，生产力会随着业务复杂度逐渐降低。所以在一些初创型公司，你更多看到的是单块应用，只有一些中大型的公司会看到微服务架构。”

　　“交叉点表明，业务已经到达了一定的复杂性，单块应用已经无法满足业务增长的需要，研发效率开始下降了，而微服务可以提升研发和交付的效率。这个点需要架构师去综合，权衡。个人经验，一般团队需要达到百人规模，才去考虑微服务。”

　　以上的观点讲的很中肯，给我的启发和帮助非常大。这里的交叉点怎么来确定和评估是重点，比如我们上线一个社交姑且叫抖信，初期为了快速上线，验证可行性，可以只开发首页聊天、通讯录、评论等基本功能。产品上线后，经过一段时间的运营，用户开始逐步增多，可行性验证通过，下一阶段就需要进一步增加更多的新特性来吸引更多的目标用户，比如再给这个社交抖信添加朋友圈、消息通知、游戏、电商等等功能。

　　“一般情况下，这个时候就需要大规模地扩张开发人员，以支撑多个功能的开发。如果这个时候继续采用单体应用架构，多个功能模块混杂在一起开发、测试和部署的话，就会导致不同功能之间相互影响，一次打包部署需要所有的功能都测试 OK 才能上线。

　　不仅如此，多个功能模块混部在一起，对线上服务的稳定性也是个巨大的挑战。比如 A 开发的一个功能由于代码编写考虑不够全面，上线后产生了内存泄漏，运行一段时间后进程异常退出，那么部署在这个服务池中的所有功能都不可访问。

　　根据我的实际项目经验，一旦单体应用同时进行开发的人员超过 10 人，就会遇到上面的问题，这个时候就该考虑进行服务化拆分了。”---胡忠想(微博微服务技术专家)

　　至此，我们何时采用微服务已经十分明确了，关键是业务复杂度和团队规模两大要点，而业务复杂度和市场窗口是权衡和抉择的首要因素。

3.2微服务落地条件评估

　　一般情况下，业务系统引入新技术就必然会带来架构的复杂度提升，在具体决策前，你先要认识到新架构会带来哪些新的问题，这些问题你和你的团队是否能够解决？如何解决？是自己投入人力建设，还是采用业界开源方案？假如你和我一样都是微服务的旁观者或者学习者，那么下面的评估也许对你又所参考。

3.2.1落地方式选择

不同的落地方式决定不同的资源配置。

方式一：借力外部架构咨询公司提供架构DEMO和培训服务助推内部团队技术转型升级。

方式二：招聘相关经验丰富的人员进来，自行研究和搭建架构并做内部培训，推动团队技术升级。

建议：如果比较紧急，采用第一种方式，因为招聘匹配的人才比较困难，等不起。但是不管是那种方式，对于团队来说都需要一定的技术人才储备方便后续交接和运维。

3.2.2人才储备

　　这里分成两类人员，一类是研究型，一类是应用型。研究型主要是以技术攻坚为主，负责微服务的核心组件的研究和开发，比如服务发布和订阅，服务跟踪和监控，服务的治理；应用型主要是负责技术理解应用为主。

3.2.3技术储备

　　微服务相关技术栈和微服务周边技术栈。周边技术栈包括领域驱动涉及，持续交付，分布式至少，负载均衡，CAP理论，缓存原理，DevOps和容器化技术。

3.2.4团队规模评估

　　杨波在给微服务的开发团队规划时候给了一个百人左右的大概预估，至于到底需要多少开发人员就没有细说，可能作者本身呆过的公司都是大厂，对人力成本控制没有那么大的包袱，对于中小企业，人力是最贵的成本。如果要一定要上微服务，该怎么办？

　　对于微服务的团队规模众说纷纭，有的说要百来号人；有的说需要精兵10人左右；有的说和人数没有关系，只和业务有关；有的说一个懂微服务的架构师也能搞定。这些说法都比较笼统，如果你想上微服务，人力评估包括人力、能力、人数等等，这些因素还是非常重要的，毕竟成本才是商业的本质，有可能不客观的规划会导致项目的溃败。

　　对于微服务的团队规模是哪些方面决定的呢？我觉得至少要从以下两个维度来评估：

　　业务规模：如果你们的业务架构非常复杂，有仓储系统开发，ERP系统，OA系统，订单系统等等，业务越多，需求人数越多(这里人数指的都是后台开发人数)。

　　技术能力：另外，别忘了非功能性的开发，比如API网关，服务跟踪、治理等也是需要人去开发和维护的，这些非功能性的核心组件需要多少人，由于没有完整的开发经验，加上个别组件，比如跟踪系统，开发的程度可深可浅，开发周期可长可短，以目前个人的经验还无法给与合理的建议。可能牛人1个人两周就够了，也可能高级开发2个人，一人分工三个核心组件，两周也够用。或者架构外包，只要交接的人能跟上，也是一种解决方案。

　　总结：1个精通微服务落地经验的架构师是必不可少的，围绕架构师周边一帮高级开发，按根据实际业务来确定，一般一个开发负责2-3个核心模块，不宜太多，比如目前核心模块有8个，对应人数配置大概在3-4个左右。

3.3转微服务风险评估

3.3.1重写面广

　　由于是架构级别的调整，之前能保留下来的大部分是解耦比较好的代码，比如前端代码，采集服务代码，部分业务逻辑代码，所以对现有框架冲击面比较大。

3.3.2复杂度高

　　因为微服务是一种观念和思想，又是新近技术，本身就有各种架构实现方式和技术解决方案。所以对技术人员来说，对比选型本身就是一个考验。加上本身涉及的技术面就比较广，所以复杂度和门槛相对比较高。

但是该技术发源于亚马逊，经过近些年的发展，虽然还在发展，但是已经相对成熟。

3.3.3人员配置

　　微服务架构工作量主要集中在后端，对后端开发人员的技术级别有较高的要求，主要是对微服务原理和开源组件的熟悉上，同时需要具备整体的微服务的意识。暂时不具备整体微服务开发意识和经验，需要通过培训后进行转型升级。

3.3.4合作方式

　　如果采用借助外部架构力量来助推架构升级，和架构单位的合作就不是简单的外包，涉及的面会变得比较广，在完全交接过来之前，周期会比较长。包括对我们业务架构的深入了解，然后根据业务架构绘制可靠技术架构蓝图，再根据技术蓝图进行落地实施(不建议只提供架构方案而由其他单位实施落地)，包括新系统的开发，旧系统的升级，当然这种升级是平滑过度的，对业务窗口并不会产生影响。

3.4合理的拆分姿势

　　如何正确拆分？这里正确指的是合理，因为没有绝对的标准。按照前人的经验可以分为纵向和横向两种划分方法：

3.4.1纵向拆分

　　是从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合多带带拆分为一个微服务，比如上图中的订单服务，用户服务。另外粒度太小，服务聚合是一个坑，粒度太大，分和没分一个样。

3.4.2横向拆分

　　是从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不与其他业务耦合。比如上图中的元数据服务和消息服务。

3.4.3总结

　　借用《微服务设计》中的一句话：“你越不了解一个领域，为服务找到合适的界限上下文就越难……服务的界限划分错误，可能会导致不得不频繁地更改服务间的协作，而这种更改成本更高……”

四、SOA和微服务

　　由于SOA和微服务有千丝万缕的关系，这里简单罗列双方的对比图，算是一个小知识点：

　　两种架构背后的意图是不同的：SOA尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。

五、总结

　　最后让我们回顾一下前人经典的话语：

• 分布式第一定律是“尽量不要使用分布式”。
• 软件行业从业者，尤其是那些已经不写代码的从业者，总会期望有银弹，但银弹终究是没有的。
• 微服务依赖于“基础设施自动化”。微服务不是“银弹”。

　　还是回到我们架构设计的原则上，遵循简单，适用，演化的原则，那么你的抉择也许会变得没有那么令人纠缠。

文章引用

• 从单体式架构迁移到微服务架构
• 《微服务设计》作者: [英] Sam Newman 出版社: 人民邮电出版社
• 4 Challenges You Need to Address with Microservices Adoption
• 为什么使用微服务？

单体架构

在传统IT行业的软件系统设计大多都是各种独立子系统的堆砌，这也就是所说的单体架构，其本身扩展性差，可靠性低，维护成本高。单体架构在初期系统规模比较小的情况下尚且能够较好的支撑，但是随着系统规模的扩大，它暴露出来的问题也越来越多，主要有以下几点：

• 复杂性逐渐变高，问题修复和新功能开发难度和成本高，引入新问题的可能性变大。同时，任意模块的缺陷都可能会影响整个系统，可靠性低。
  
• 随着人员流动，加之复杂性高，新的问题很难被发现和解决，久而久之，问题逐渐变多，变难、变大，技术债务逐渐上升。
  
• 随着模块不断集成，部署速度逐渐变慢
  
• 想进行整体的技术创新基本不可能，阻碍技术创新
  
• 垂直和水平的可扩展性差
  

SOA架构

随后，引入了SOA服务化（面向服务的架构，它将应用程序的不同功能单元（服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来)。但是，由于 SOA 早期均使用了ESB总线模式，这种总线模式与某种技术栈是强绑定的，如，J2EE。这又使得很多企业的遗留系统很难对接，切换时间太长，对接成本太高，新系统稳定性的收敛也需要一些时间。最终 SOA 看起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。

SOA服务化思想下的微服务架构

微服务是在 SOA 上做的升华，微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP Rest API的方式（告别ESB服务总线），这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

简单讲，微服务不再强调传统SOA架构里面比较重的ESB服务总线，同时将SOA的思想延伸到单个业务系统内部实现真正的组件化。微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”。

从微服务的概念可以看出它有如下好处：

• 每个服务可以独立开发，易于开发，提高开发人员的生产效率
  
• 局部修改容易部署
  
• 技术栈不受限
  
• 单个服务支持独立部署和发布，可以进行快速迭代部署，更快的交付时间
  
• 更有利于业务的扩展，可伸缩性强

转自 @软件测试开发技术栈 ，希望对您有所帮助。

单体架构：

单体机构是指在软件设计中使用经典的 3 层模型，即表示层、业务逻辑层和数据访问层。虽然在设计中划分了 3 层模型，但是对业务场景没有划分。一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包，部署在一台服务器上。

优点：

1. 易于开发: 单体应用程序开发相对简单，容易理解，单个程序员可以完成业务接口到数据库的整个流程。
2. 部署简单: 由于是完整的结构体，可以直接部署在一个服务器上即可。
3. 技术单一: 项目不需要复杂的技术栈，往往一套熟悉的技术栈就可以完成开发。

缺点：

1. 开发成本高：代码重复率高，需求变更困难，无法满足新业务快速上线和敏捷交付。
2. 系统稳定性差：任何一个模块的错误均可能造成整个系统的宕机;
3. 扩展能力受限：系统的扩容只能只对这个应用进行扩容，不能做到对某个功能点进行扩容，关键性的代码改动一处多处会受影响。

SOA架构:

SOA架构即面向服务架构，是一种粗粒度、松耦合服务架构。基于SOA服务思想进行功能的抽取，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来，以服务为中心各个系统之间依靠ESB企业服务总线进行调用，这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

优点：

1. 敏捷性：可以直接利用现有的资源进行组合，让后在按照自己的客户需求，进行进一步的开发。
2. 扩展性：可以更具不同的需求，进行重新的组合和构造。
3. 易维护：服务的提供者和使用者是松耦合关系，开放标准接口的采用，使其具有很好的维护性和可用性。

缺点：

1. 开发难度: 架构设计、服务抽取、接口设计等问题，考验着领导者和开发人员过硬的技术能力。
2. 数据统一：存在“脏数据”相关问题，处理一致性是设计服务接口面临的巨大挑战之一。

微服务架构：

微服务架构是把一个大型的单个应用程序和服务拆分为多个的微服务，每个微服务仅关注并很好的完成一件任务。它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

优点：

1. 独立性：是每个微服务组件都是简单灵活的，能够独立部署。
2. 可扩展性：微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展，产品迭代周期更短。
3. 隔离性：每个微服务都是独立的运行，任何一个或者多个微服务的失败只影响自己或者少量其他微服务，而不会大面积地波及整个服务运行体系。

缺点：

1. 复杂性：开发的复杂性增加，因为一个业务流程需要多个微服务通过网络交互来完成。
2. 服务治理：微服务过多，服务治理成本高，不利于系统维护。

其实，这三者到现在来说未必是那样经纬分明、非此即彼，很多基于微服务的单体架构应用、结合分布式的SOA云服务总线来实现线上线下集成、内部跟外部集成、构建柔韧的企业IT架构、满足业务的变化、推动业务创新和变革，是软件架构不断优化、变迁、提升的源动力。

数通畅联专注于企业IT架构、SOA综合集成、数据治理分析领域，感谢您的阅读与关注

一图了解什么是单体架构、SOA架构、微服务架构

分别从三个维度来展示：

1、软件过程维度

单体架构通常采用瀑布模型开发；

SOA架构通常采用敏捷/XP编程模式；

微服务架构采用DevOps，使用IT交付流水线来全自动管理；

2、从架构维度

单体架构通常采用巨石结构，不易维护；

SOA架构通常以服务的方式对外连接，常见的支撑平台有ESB企业服务总线进行服务贯通；

微服务架构采用更细的拆分模式，每个独立的模块有多带带的数据库、运行环境，在业务上完成一个具体的功能；

3、从部署形态维度

单体架构早期多运行在物理机中，当然后期也可以运行在虚拟化资源中；

SOA架构多运行在虚拟化/IAAS平台上；

微服务架构目前多运行在容器平台上（当然也可以运行在虚拟化资源和物理机中，这种情况享受不到容器带来的便利性）；

单体架构

* 一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包，部署在一台服务器上。

`例如：典型的J2EE工程，它是将表示层的JSP、业务逻辑层的Service、Controller和数据访问层的Dao，打成war包，部署在Tomcat、Jetty或者其他Servlet容器中运行`

SOA架构

* SOA架构是面向服务的体系结构，主要目的是为了各个系统更加容易地融合在一起。

`例如：以购物商城为例，由于功能模块越来越多，系统非常臃肿所有对系统进行横向拆分，各个服务之间彼此相对独立，通过服务治理框架进行服务之间的通信以及管理，常用的服务治理框架有：dubbo、dubbox等`

微服务架构

微服务是将一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务模块。

我在低代码开发平台领域中接触最多的就是微服务架构，微服务是指开发一个单个 小型的但有业务功能的服务,每个服务都有自己的处理和轻量通讯机制,可以部署在单个或多个服务器上，而且部署方式也有多种，集群部署，双机部署，单机部署等等，天翎的myapps平台就是一个很好的例子，可以去了解一下这个架构，是三种架构里面使用得比较多也比较方便的软件产品架构

表面上看这是一个大问题。

实质有内联关系。

你可以把一个单体架构的应用看作是一大整块豆腐。

SOA架构就是豆腐切块了。

微服务架构就是豆腐切块了之后又切成豆腐丁了。

大块有大块的好处，小块有小块的好处。

这里的利弊就是你打算怎么个做法能吃起来更可口。

应用切分到微服务也并不是绝对的好。

技术架构细分也是软件细化分工的一种体现。

仅此而已。