科普篇 — 单体、SOA、微服务架构及中台
系统应用架构的变迁
第一代:单体架构
将所有功能模块打包到一起,并放在一个容器中运行。
比如,搭建有一个物质管理系统:资产盘点、出入库、定位、维修、报废等一系列操作。在使用单体架构时,那么就是将这一系列服务都放在一个服务器中,这种将所有功能部署在一个容器中运行的系统就叫单体架构。
优点 | 缺点 |
---|---|
容易测试,在本地就可以启动完整的系统 | 需求的增加,不断往容器中添加服务,显得臃肿笨拙 |
容易部署,直接打包为一个完整的包,拷贝到容器中即可运行 | 修改一个地方则需要整个系统重新部署 |
容易开发:开发方式简单,方便运行和调试(适用于较为简单的系统) | 不利于更新技术框架,除非将系统重构 |
. | 维护成本大,扩展性差 |
第二代:面向服务架构(SOA)
在了解SOA之前,先简单了解企业服务总线
企业服务总线(ESB):
ESB是面向服务架构(SOA)的核心构成部分,指传统数据连接技术(web、xml、中间件技术)结合的产物,简单来说,就是一根管道,用来连接各个服务节点,为了集成不同系统,不同协议的服务,服务总线做了消息的转化解释和路由工作,让不同的服务互联互通;是一个具有标准接口、实现了互连、通信、服务路由。
总线需要具备的功能:1、服务统一管理:为整个系统提供一个统一、标准。可靠 、可扩展的服务管理平台。
2、集成服务:提供基础的服务与定制的服务,支持集成服务模式,支持服务的分解,服务调度和路由、封装及组合。
3、公用服务:提供内置的各种公共服务,如,认证服务、日志服务等。
4、服务协议转换:通过把不同的通信协议转换为标准的报文,屏蔽异构系统的底层技术差异。
5、服务监控:提供服务等级管理及流量管理。
6、安全体系:提供多种安全机制并支持和第三方安全系统的有效集成。
SOA是集成多个较大组件(一般是应用)的一种机制,将整体构成一个彼此协作的套件,一般来说,每个组件会从始至终执行一个完整的业务逻辑。SOA中包含多个服务,服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间,通过网络调用。
特点:1、系统集成:从系统角度讲,解决了企业系统与系统间通信问题,把原来散乱、无规划的系统间的网状结构梳理成规整,可治理的系统。在梳理时则需要引用一些产品,常用的是企业服务总线(ESB)、技术规范、服务管理规范。主要解决核心问题,无序变有序。
2、系统的服务化:从功能角度讲,把业务转换成可复用、可组装的服务,通过服务的编排实现业务的快速复制。目的是把原先固有的业务功能转变为通用的业务服务,实现快速复用。主要解决的核心问题,原来固有业务可复用。
3、业务的服务化:从企业的角度讲,把原来职能化的企业架构转变为服务化的企业架构,进一步提升企业的对外服务能力。把一个业务单元封装成一项服务。主要解决的核心问题是高效。
优点 | 缺点 |
---|---|
数据统一,共享数据库,使服务接口使用同一的数据模型的数据,确保数据一致性 | 技术不匹配,在某些情况并不能轻松对操作平台进行重新打包,原因是业务功能结构需求不匹配 |
灵活性较高,缩短产品和服务的上线时间,降低了开发与改变流程的成本 | 系统间交互需要使用远程通讯 ,一定程度上降低了响应速度 |
系统由子系统组成,系统易于重构 | . |
第三代:微服务架构
跟SOA类似,在SOA上做了升华,微服务架构强调业务需要彻底的组件化和服务化,在微服务架构中,系统的业务逻辑被拆分成为一系列小而松散耦合的分布式组件(组件一般指应用),共同构成较大的应用。每个组件都被称为微服务,而每个微服务都在整体架构中执行着单独的任务或单独的功能。每个微服务可能会被一个或多个其它微服务调用,以执行较大应用需要完成的具体任务。
比如:假设一个APP中有积分体系功能,现需要更新积分,只需要更新发布积分的微服务即可,其他的功能正常运行,不受影响。而不是将整个业务系统都停掉,所有的功能都要暂停一会儿,等发布积分的服务才能使用。
特点:1、通过服务实现组件化,开发者不再需要协调其它服务部署对本服务的影响。
2、按业务能力来划分服务和开发团队,开发者可以自由选择开发技术,提供API服务 即可。
3、去中心化:
每个微服务都有自己私有的数据库来持久化业务数据。
每个微服务只能访问自己的数据库,而不能访问其他服务的数据库。
某些业务场景下,需要在一个事务中更新多个数据库,这种情况也不能直接访问其它微服务的数据库。
降低微服务之间的耦合度,不同服务可以采用不同的数据库技术。
在复杂的的业务场景下,如果包含多个微服务,通常在客户端或者中间层(网关)处理。
优点 | 缺点 |
---|---|
部署简单,每个服务承担少数职责,波及范围小 | 系统整体延迟增加,原来的函数调用改为服务调用 |
易于扩展,某一项服务的性能达到瓶颈,只需增加该服务的节点数即可,其它服务不改变 | 每个服务都需要单独部署,运维、测试成本增加 |
减低资源的耦合性,服务独立,数据源唯一 | 前期服务的定义和拆分需要较大工作量 |
易于维护,每个微服务的职责单一,复杂性降低,不会牵一发而动全身 | . |
面向服务架构(SOA)与微服务的主要区别:
功能 | 面向服务(SOA)架构 | 微服务架构 |
---|---|---|
耦合性 | 一般是松耦合 | 总是松耦合 |
公司架构 | 任何类型 | 小型、专注于功能交叉团队 |
管理 | 着重中央管理 | 着重分散管理 |
目标 | 确保应用能够交互操作 | 执行新功能、快速拓展开发团队 |
系统组成 | 由多个子系统组成 | 由多个组件组成 |
应用部署 | 相互依赖,部署复杂 | 独立部署,互不影响 |
数据管理 | 全局数据模型,共享数据库 | 每个服务都有自己的数据模型或数据库 |
服务架构 | 企业服务总线,集中式的服务架构 | 无集中式总线,松散的服务架构 |
中台
中台并非完全是自上向下的战略设计,也非是为了追随行业风口,可以理解为一种产品设计思路或系统架构的思路。
中台是随着公司业务高速发展,组织不断膨胀的过程中暴露的问题需要解决。将企业的核心能力随着业务不断发展以数字化形式沉淀到平台,形成以服务为中心,由业务中台和数据中台构建起数据闭环运转的运营体系,供企业更高效的进行业务探索和创新。
中台做到前后分离,后台统一提供数据接口,前台实现业务流转。
中台与微服务的区别:
中台是提升企业的能力的复用,一种方法论/思想。
微服务是独立开发、维护、部署的小型业务组件,一种技术架构。
中台与微服务的关系:
微服务架构,是实现中台思想的落地的重要手段。
中台解决的核心问题:
为减少重复业务系统开发及实现系统数据共享一个技术平台底座,将多年技术沉淀的价值最大化,统一各个业务部门或系统重复使用、重复建设的功能和系统统一规划和管理。
什么时候需要中台:
如阿里:淘宝,有订单、库存、评价、积分、物流等业务系统。天猫也有订单、库存、评价、积分、物流等业务系统。1688,也有类似业务系统。多个系统有重复业务系统需要建设,且系统间数据不能完全共享,系统各自运行。此时使用技术中台以及业务中台,来实现业务重用及数据共享,把技术沉淀价值最大化。
借用网上的回复:
微服务就是:将整个军队分散为若干军区,每个军区之间确定各自驻防的边界划分,至于各军区如何行军、如何存放军火、如何部署兵力,不作统一规定,各军区自行决断,各军区的人当然也不能进入其他军区的地盘,但各作战单位必须遵守共同的通讯频道,必须满足对其他军区的服务契约。
中台就是:建立强大的火箭军、炮兵。空军。无人机部队、信息化部队等,如此一来,前方作战小分队可以很小,一个班的人要攻打一个山头,只要侦查清楚这个山头的特定地形和敌军布防,然后就根据情况呼叫空军地毯式轰炸。呼叫炮兵火力覆盖、呼叫无人机定点清除、呼叫信息化部队电子干扰...一个班就可以搞定。
虽然这两个概念并不互斥,但是微服务听起来更像是【守城】,就是对现有地盘的加强和巩固。而中台更支持【开拓】,主要目的是更灵活的拓展新的业务。
原文链接:jianshu.com/p/a5894e8ba3f3