直播了！构建基于ServiceMesh的中台架构！
【第一部分-ServiceMesh】
服务网格 （ServiceMesh）这两年异常之火，号称是下一代微服务架构。
ServiceMesh到底解决什么问题呢？
微服务架构中，随着数据量不断增大，吞吐量不断增加，业务越来越复杂，服务的个数会越来越多， 分层会越来越细 ，除了 数据服务层 ，还会衍生出 业务服务层 ， 前后端分离 等各种层次结构。
不断发现主要矛盾，抽离主要矛盾，解决主要矛盾，架构自然演进了，微服务架构， 潜在的主要矛盾会是什么呢？
引入微服务架构，一般会引入一个RPC框架，来完成整个RPC的调用过程。
如上图粉色部分所示，RPC分为：
-
RPC-client，它嵌在调用方进程里
-
RPC-server，是服务进程的基础
如此这般，越来越多和RPC，和微服务相关的功能，会被加入进来。
例如： 负载均衡
如果要扩展多种负载均衡方案，例如：
-
轮询
-
随机
-
取模
-
一致性哈希
RPC-client需要进行升级。
例如： 数据收集
如果要对RPC接口处理时间进行收集，来实施统一监控与告警，也需要对RPC-client进行升级。
又例如： 服务发现
服务新增一个实例，通知配置中心，配置中心通知已注册的RPC-client，将流量打到新启动的服务实例上去，迅猛完成扩容。
再例如： 调用链跟踪
如果要做全链路调用链跟踪，RPC-client和RPC-server都需要进行升级。
上述功能，其实都不是业务功能，所以 互联网公司一般会有一个类似于“架构部”的技术部门去研发和升级相关功能 ，而业务线的技术部门直接使用相关框架、工具与平台，享受各种“黑科技”带来的便利。
完美！！！
理想很丰满，现实却很骨感，由于：
-
RPC-client，它嵌在调用方进程里
-
RPC-server，是服务进程的基础
往往会面临以下一些问题：
-
业务技术团队，仍需要花时间去学习、使用基础框架与各类工具，而不是全心全意将精力花在业务和产品上
-
client要维护m个版本， server要维护n个版本，兼容性要测试m*n个版本
-
如果要支持不同语言，往往要开发C-client，Python-client，go-client，Java-client多语言版本
-
每次“黑科技”的升级，都需要推动上下游进行升级，这个周期往往是以季度、半年、又甚至更久，整体效率极低
画外音： 兄弟，贵司推广一个技术新产品，周期要多长？
这些耦合，这些通用的痛点，有没有办法解决呢？
一个思路是， 将服务拆分成两个进程 ，解耦。
-
一个进程实现业务逻辑（不管是调用方，还是服务提供方）， biz ，即上图白色方块
-
一个进程实现底层技术体系， proxy ，即上图蓝色方块
-
biz和proxy共同诞生，共同消亡，互为 本地部署 ，即上图虚线方框
-
biz和proxy之间，为 本地通讯 ，即上图黑色箭头
-
所有biz之间的通讯，都通过proxy之间完成，proxy之间才存在 远端连接 ，即上图红色箭头
这样就实现了“ 业务的归业务，技术的归技术 ”，实现了 充分解耦 ，如果所有节点都实现了解耦，整个架构会演变为：
-
绿色为biz
-
蓝色为proxy
整个服务集群变成了网格状，这就是ServiceMesh服务网格的由来。
【第二部分-中台】
“小前台，大中台”是很多公司为了快速落地业务，进行的组织变革与系统架构变革。 中台的目的是复用 ：业务复用，组织复用，系统复用。
要想落地中台，一定要有组织机制支持。 组织不变，光系统架构变，各研发团队职责不清，反而会形成各自为战的局面，各占山头，重复建设，变成包袱。 中台战略，一定是自上而下推动的 。
当然， 中台战略，未必适合所有公司么。 例如：初创公司，业务单一的公司，产研团队较小的公司，并不适合中台。中台战略，特别适合 有一定规模，有多块业务 ，或者 希望快速进行业务创新尝试 的公司。中台战略的落地，能够最大程度的“减少重复建设轮子”。
相对通用的业务，都有做成中台的可能性 。例如：用户，订单，支付，商品，营销等通用的业务模块，非常适合做中台。
【福利来了】
活动 ：直播
话题 ： 如何利用ServiceMesh技术，快速构建中台架构
时间 ：今晚20:00
嘉宾 ：孙玄
扫码 参与今晚直播
1.99 ，买不了吃亏，买不了上当，获取一个和大神当面聊架构的机会。
阅读原文 ，直接参与。
正文到此结束
热门推荐
相关文章
Loading...
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
