写点什么

【总结】企业级案例驱动 打造高可用、高并发、多 IDC 部署业务中台微服务架构

用户头像
魔曦
关注
发布于: 2020 年 06 月 26 日

企业级微服务架构的实践理论

focus on service(架构设计)普适(金融、互联网等各行业)

架构师分类:

NX 复杂事情搞成简单的,简单的事情搞成没有了;千万别炫技

SB 简单事情,搞复杂,复杂事情搞不定

业务拆分方案(数据库的拆分类似)

功能水平拆分->分表

业务垂直拆分->分库

API粒度拆分->读写拆分为单独的服务,互联网行业服务偏重读,但是特殊的场景写很重要,比如用户的注册,一旦用户注册失败,肯定不会再来,需要将读服务、写服务拆分;

读写服务拆分后,如何解决主从库之间的延时问题呢?用户注册成功了,但是执行登录在从库查不到记录,

解决方案1 按照用户ID将用户分库,分库后所有的读可以直接读主库

解决方案2 数据量不大的情况下,可以设置主从之间强同步,而不采用半同步方式

解决方案3 引入redis,通过分布式事务来保证写数据库与redis的一致性,读操作从redis获取,或者从库读不到,强制读主库等将简单问题复杂化->SB

用户执行了一个修改操作,修改登录的用户名这个时候读操作如何做呢?

此时的读操作是无法辨识读到的数据是否最新的,如何解决呢?从业务和技术两个维度来搞,从业务来说判定是否允许一定的延时,如果允许那么就是用户读的是一个旧数据,多刷几次肯定能读到新数据;要么就采用上述的方案2



网关层做了什么事情?

1、请求鉴权

2、协议转化 将http协议转化为二进制,企业内部传递采用http性能是有问题的,企业内部采用tcp协议

3、路由转发

4、通用参数检查 定长部分参数,验证参数的完整性,不会验证参数的语义



数据访问层->屏蔽底层存储的差异性

1、CRUD

2、ORM

3、Sharding 难度大

4、其他



同步架构OR异步架构

一种架构模式不可能通吃,所以不可能只存在一种模式

同步架构

异步架构

目标:提升吞吐量

在那一层做解耦呢?网关层与业务逻辑层加入MQ(任何两层之间加入一层都可以变为异步,比如加入MQ,但是上游和MQ之间是同步,下游和MQ之间是同步,整个链路的耗时会增加,MQ写是顺序写,性能比较高),为何不增加在APP与网关层之间呢,当然因为网关层可以帮我们过滤掉一部分无用的请求

适用场景

请求类型

读请求 异步不是OK

写请求 写请求按照场景可以做异步,CP或者AP模式下需要注意,比如招商银行转账采用异步方式转账完成,通过一个提示转成在进行完成后会push信息,这个方案在很多场景都在采用

业务类型

金融

社交SNS

总结

常用方法 拆、合

服务调用是从上往下,不会出现同一层级之间的循环依赖

场景balance设计思维模型

CAP架构设计思维模型

掌握哲学本质架构设计思维模型(从北京到上海 座高铁或者火车效果是不一样的)



企业级微服务架构分布式事务设计与实践(架构设计)

focus on data

分布式事务解决方案

1.将分布式事务变成多个本地事务

2.协调多个本地事务

分布式事务模型

CP模型

XA模型:基本实现两阶段提交、三阶段提交 吞吐量上不去,由于存在全局锁

AP模型->互联网常用

同步场景 saga模型 seate是一个解决方案,既支持CP也支持AP。

异步场景 A->DB1 A操作产生消息到MQ,B、C订阅MQ消息,执行对应的操作,B->DB2,C->DB3 引入本地事务消息表,A操作时将写本地事务与写本地事务消息表放在同一个事务中,执行完成后本地事务消息表的msgid放入事务操作队列中(内存队列,重启会丢失),

1.发送端消息不幂等 at least once

2.消费端处理消息幂等,分布式锁或者消息去重表等

3.A->B-C A、B成功,C失败,如何处理?人工智能:记录错误日志,报警人工介入

4.优点 业务侵入小

Q&A MQ下游的消费服务如何保证事务的成功处理?





企业微服务架构跨国际化多IDC部署设计与实践(运维&部署)

focus on deploy

OP SRE DevOps AiOps NoOps

百度空间 (space uid spaceid spaceurl)/微信朋友圈/微博

用户跨国际注册

国内

服务如何部署? 服务无状态化stateless

数据如何部署? 数据有状态statefull

数据如何同步? 一个主机房,一个从机房;写入经过LVS-Nginx层全部打到主机房进行写,MySQL、Redis等通过机房间的专用线路进行同步;多主引擎比如Pika没有同步机制的服务如何搞呢?先将数据写入MQ(主从),Pika从主机房或者从机房的MQ进行消费;主机房的MySQL会配置多个从,防止挂掉,如果挂了从机房需要监控新主节点,MHA

CP、AP两种模式数据同步不一样,同步方式 多主引擎户出现数据不一致,可以强制读主,但是RT会增加

常识:每一千公里ping的延迟在20ms





国外

多活,饿了么国内多活,详见知乎饿了么专区

服务如何部署? 服务无状态化stateless

数据如何部署? 数据有状态statefull

数据如何同步? 如何解决冲突?定义偏序关系,push信息给用户(产品侧包容);update、delete是否存在偏序关系呢?



企业级业务中台微服务架构实践方法论

中台模式

中台的起源

芬兰移动游戏公司Supercell以小前台方式组织开发团队

如何构建中台?

业务中台、技术中台、算法中台、数据中台,

通用能力/功能下沉为公共服务

服务之间的连接如何解决?一键接入

如何落地中台?

架构选择可以是微服务架构、ServiceMesh、SOA、CloudNative、单体架构等;需要组织架构、业务架构、技术架构全面支持;

新增业务一键接入众多业务中台系统

业务注册中心、业务配置中心、业务分发中心



业务中台数据存储如何支持多业务接入,场景C2C、B2C、C2B2C的商品数据如何存储?个性化数据+共性数据

个性化数据放置在业务本地,会造成后期一些数据的孤岛

方案1 个性化数据每个业务一张表,系统的表将会爆炸式增长,不可控

方案2 一个公共表,一个个性化扩展表;假如个性化表最多64个字段可以满足需求,64个列,列的类型可以是Long,Double,text满足条件,则按照三个类型平分64列,key1...key64,将对应的key与业务个性化的字段做对应,比如key1->验机等,这个表就是映射表,但是存在数据空洞问题,相对而言空洞问题到还好是可控的。

方案3 从schema到no schema,比如NoSQL的MongoDB collection,数据库不需要知道存储的数据的语义,语义需要业务方去了解,但是不支持集群,扩展性有问题

方案4 方案2是列扩展,方案4行扩展,那么会出现什么问题?查询问题、数据量大、类型转化等(infoID,type数据类型1int等,key业务字段,value业务字段的值)

选择大于努力!!!考虑关键因素

业务中台数据统一存储,前台业务数据单独存储



企业级业务中台微服务架构高可用设计与实践(微博案例)

微博服务突发大流量

鹿晗事件 只影响鹿晗、关晓彤的微博不能访问了,隔离性比较好,其他人的微博还是可以访问的

热点问题如何解决?

问题产生原因或者瓶颈点在哪里?

1.数据库层面

2.缓存层面(redis cluster模式,数据肯定存在其中一台机器)

3.其他各层都是无状态,可以迅速扩展

读->压力

写->压力 feedId、feedContent...,异步化(点赞、转发、评论)

写放大

解决方案

热点分散(随着请求数量的增加,将热点数据分布到数据访问层的cache也就是进程间的cahce或者是本地缓存)

热点预测->预测系统,根据日志分析是否为热点,将热点数据push的本地缓存等



微博为何不能彻底解决大流量挂掉的问题?

ROI投入和产出不成正比,所以不会完全搞定的,秒级扩展不太现实(扩展需要时间),除非是预留否则肯定会出问题,即使预留了超出了预留的极限也会出问题,618JD、天猫也会出现挂掉的case

优秀架构师快速成长之路(认知、思维、格局)

认知

思维

格局



发布于: 2020 年 06 月 26 日阅读数: 247
用户头像

魔曦

关注

我思故我在! 2018.01.15 加入

凡事有交代,件件有着落,事事有回音。

评论

发布
暂无评论
【总结】企业级案例驱动 打造高可用、高并发、多IDC部署业务中台微服务架构