【架构】架构服务化
参考⾃：
单体分层架构
在 Web 应⽤程序发展的早期，⼤部分⼯程是将所有的服务端功能模块打包到单个巨⽯型（Monolith）应⽤中，譬如很多企业的 Java 应⽤程序打包为 war 包，最终会形成如下的架构：
巨⽯型应⽤易于搭建开发环境、易于测试、易于部署；其缺陷也⾮常明显，⽆法进⾏局部改动与部署，编译时间过长，回归测试周期过长，开发效率降低等。集中式架构分为标准的三层：数据访问层、服务层和 Web 层。
在 Web2.0 时代刚刚流⾏的时候，互联⽹应⽤与企业级应⽤并没有本质的区别，集中式架构分为标准的三层：数据访问层、服务层和 Web 层。
数据访问层⽤于定义数据访问接⼝，实现对真实数据库的访问；
常用微服务架构
服务层⽤于对应⽤业务逻辑进⾏处理；
Web 层⽤于处理异常、逻辑跳转控制、页⾯渲染模板等。
⾯向服务架构 - SOA
SOA（Service-Oriented Architecture） ⾯向服务架构，是在互联⽹应⽤规模迅速增长，集中式架构已⽆法做到⽆限制地提升系统的吞吐量的背景下，产⽣的涉及模块化开发、分布式扩展部署等相对宽泛的概念。
SOA 是⼀个组件模型，它将应⽤程序的不同功能单元（称为服务）通过这些服务之间定义良好的接⼝和契约联系起来。SOA 中的接⼝独⽴于实现服务的硬件平台、操作系统和编程语⾔，采⽤中⽴的⽅式进⾏定义。这使得构建在各种各样的系统中的服务可以以⼀种统⼀和通⽤的⽅式进⾏交互。⾯向服务架构，它可以根据需求通过⽹络对松散耦合的粗粒度应⽤组件进⾏分布式部署、组合和使⽤。服务层是 SOA 的基础，可以直接被应⽤调⽤，从⽽有效控制系统中与软件代理交互的⼈为依赖性。
实施 SOA 的关键⽬标是实现企业 IT 资产的最⼤化作⽤。要实现这⼀⽬标，就要在实施 SOA 的过程中牢记以下特征：可从企业外部访问、随时可⽤、粗粒度的服务接⼝分级、松散耦合、可重⽤的服务、服务接⼝设计管理、标准化的服务接⼝、⽀持各种消息模式、精确定义的服务契约。
服务消费者（Service Consumer）可以通过发送消息来调⽤服务，这些消息由⼀个服务总线（Service
Bus）转换后发送给适当的服务实现。这种服务架构可以提供⼀个业务规则引（Business Rules Engine），该引擎容许业务规则被合并在⼀个服务⾥或多个服务⾥。这种架构也提供了⼀个服务管理基础（Service Management Infrastructure），⽤来管理服务，类似审核，列表（billing），⽇志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（Regulatory Requirement），例如 Sarbanes Oxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。
由于分布式系统⼗分复杂，因此产⽣了⼤量的⽤于简化分布式系统开发的分布式中间件和分布式数据库，服务化的架构设计理念也被越来越多的公司所认同。如下是 Dubbo 官⽅⽂档公布了⼀张有关 SOA 系统演化过程的图⽚：
微服务架构 - Microservices
微服务（Microservices Architecture Pattern）由 Martin Fowler 在 2014 年提出的，是希望将某个单⼀的单体应⽤，转化为多个可以独⽴运⾏、独⽴开发、独⽴部署、独⽴维护的服务或者应⽤的聚合，从⽽满⾜业务快速变化及分布式多团队并⾏开发的需求。如康威定律（Conway’s Law）所⾔，任何组织在设计⼀套系统（⼴义概念）时，所交付的设计⽅案在结构上都与该组织的通信结构保持⼀致，微服务与微前端不仅仅是技术架构的变化，还包含了组织⽅式、沟通⽅式的变化。
对于微服务，不同背景的⼈也有不同的见解，对于熟悉 SOA 的开发者，微服务也可以认为是去除了 ESB 的 SOA 的⼀种实现⽅案；ESB 是 SOA 架构中的中⼼总线，设计图形应该是星形的，⽽微服务是去中⼼化的分布式软件架构。SOA 更多强调重⽤，⽽微服务偏向于重写。SOA 偏向⽔平服务，微服务偏向垂直服务；SOA 偏向⾃上⽽下的设计，微服务偏向⾃下⽽上的设计。
微服务与微前端原理和软件⼯程，⾯向对象设计中的原理同样相通，都是遵循单⼀职责(Single Responsibility)、关注分离(Separation of Concerns)、模块化(Modularity)与分⽽治之(Divide & Conquer)等基本的原则。从巨⽯型应⽤到微服务的衍化也并⾮⼀蹴⽽就，如下图也演⽰了简单的渐进式替代过程：
云原⽣架构 - Cloud Native

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。