原文出处： JoeCao
微处事架构和SOA区别
微处事此刻辣么火，业界风行的比拟的却都是所谓的Monolithic单体应用，而大量的系统在十几年前都是已经是漫衍式系统了，那么微处事作为新的理念和本来的漫衍式系统，可能说SOA（面向处事架构）是什么区别呢？
我们先看沟通点：
需要Registry，实现动态的处事注册发明机制；
需要思量漫衍式下面的事务一致性，CAP原则下，两段式提交不能担保机能，事务赔偿机制需要思量；
同法式用照旧异步动静通报，如何担保动静靠得住性？SOA由ESB来集成所有的动静；
都需要统一的Gateway来汇聚、编排接口，实现统一认证机制，对外提供APP利用的RESTful接口；
同样的要存眷如何再漫衍式下定位系统问题，如何做日志跟踪，就像我们电信规模做了十几年的信令跟踪的成果；
那么不同在哪？
是一连集成、一连陈设？对付CI、CD（一连集成、一连陈设），这自己和火速、DevOps是交叉在一起的，我认为这更倾向于软件工程的规模而不是微处事技能自己；
利用差异的通讯协议是不是区别？微处事的标杆通讯协议是RESTful，而传统的SOA一般是SOAP，不外今朝来说回收轻量级的RPC框架Dubbo、Thrift、gRPC很是多，在Spring Cloud中也有Feign框架将尺度RESTful转为代码的API这种仿RPC的行为，这些通讯协议不该该是区分微处事架构和SOA的焦点不同；
是风行的基于容器框架照旧虚拟机为主？Docker和虚拟机照旧物理机都是架构实现的一种方法，不是焦点区别；
微处事架构的精华在切分
处事的切分上有较量大的区别，SOA原本是以一种“集成”技能呈现的，许多技能方案是将原有企业内部处事封装为一个独立历程，这样新的业务开拓就可重用这些处事，这些处事很大概是雷同供给链、CRM这样的很是大的颗粒；而微处事这个“微”，就说明白他在切分上有考究，不当协。无数的案例证明，劳务派遣管理系统，假如你的切分是错误的，那么你得不到微处事理睬的“低耦合、进级不影响、靠得住性高”之类的优势，而会比利用Monolithic有更多的贫苦。
不拆分存储的微处事是伪处事：在实践中，我们经常见到一种架构，后端存储是全部和在一个数据库中，仅仅把前端的业务逻辑拆分到差异的处事历程中，本质上和一个Monolithic一样，软件开发，只是把模块之间的历程内挪用改为历程间挪用，这种切分不行取，违反了漫衍式第一原则，模块耦合没有办理，机能却受到了影响。
漫衍式设计第一原则 — “不要漫衍你的工具”
微处事的“Micro”这个词并不是越小越好，而是相对SOA那种粗粒度的处事，我们需要更小更符合的粒度，这种Micro不是无限制的小。
假如我们将两路（同步）通信与小/微处事团结利用，并按照好比“1个类=1个处事”的原则，那么我们实际上回到了利用Corba、J2EE和漫衍式工具的20世纪90年月。遗憾的是，新生代的开拓人员没有利用漫衍式工具的履历，因此也就没有认识到这个主意何等糟糕，软件开发，他们正试图反复汗青，只是这次利用了新技能，好比用HTTP代替了RMI或IIOP。
微处事和Domain Driven Design
一个简朴的图书打点系统必定无需微处事架构。既然回收了微处事架构，那么面临的问题空间一定是较量弘大，好比整个电商、CRM。
如何拆解处事呢？
利用什么样的要领拆解处事？业界风行1个类=1个处事、1个要领=1个处事、2 Pizza团队、2周能重写完成等要领，可是这些都缺乏实施基本。我们必需从一些软件设计要领中寻找，面向工具和设计模式合用的问题空间是一个模块，而函数式编程的理念更多的是在代码层面的微观上起浸染。
Eric Evans 的《规模驱动设计》这本书对微处事架构有很大警惕意义，这本书提出了一个能将一个大问题空间拆解分为规模和实体之间的干系和行为的技能。今朝来说，这是一个最公道的办理拆分问题的方案，透过限界上下文（Bounded Context，下文简称为BC）这个观念，我们能将实现细节封装起来，让BC都可以或许实现SRP（单一职责）原则。而每个微处事正是BC在实际世界的物理映射，切合BC思路的微处事相互独立松耦合。
微处事架构是一件功德，逼着各人存眷设计软件的公道性，假如本来在Monolithic中规模阐明、面向工具设计做欠好，换微处事会把这个问题成倍的放大
以电商中的订单和商品两个规模举例，凭据DDD拆解，他们应该是两个独立的限界上下文，可是订单中必定是包括商品的，假如贸然拆为两个BC，查询、挪用干系就耦合在一起了，甚至有了贫苦的漫衍式事务的问题，这个关联如何拆解？BC理论认为在差异的BC中，纵然是一个术语，他的存眷点也纷歧样，在商品BC中，存眷的是属性、规格、详情等等（实际上商品BC这个规模有价值、库存、促销等等，把他作为单唯一个BC也是不公道的，这里为了简化例子，各人先认为商品BC就是商品基本信息）， 而在订单BC中更存眷商品的库存、价值。所以在实际编码设计中，订单处事往往将存眷的商品名称、价值等等属性冗余在订单中，这个设计摆脱了和商品BC的强关联，两个BC可以独立提供处事，独立数据存储
小结
首页
微信交流
关注我们