架构思维提升,掌握架构本质

开篇先回到2018年,当时在和一个大型客户做中台+微服务的交流中提到“微服务是一种架构模式,微服务和云,中台都不是强耦合的”。客户一位负责人还确认性问了句,“也就是说微服务可以不用上云”,当时我给了肯定的回答。时至今日,通过不断的学习和实践,对很多东西有了更更深的认识。另外这两年云原生开始火起来,那么是不是应用跑在了云上,就是云原生呢?随着公有云越来越成熟,很多创业公司,一开始就选择了公有云平台。在公有云上买资源,部署应用。这是云原生吗?我认为其实不是。先来说说云计算,其本质就是按需分配资源和弹性计算。云原生是一种设计模式,而云原生应用是专门为云平台部署和运行而设计的应用,可以充分利用云平台的弹性能力,实现柔性。因此仅仅把应用部署在云上,把云当作物理机的高效替代使用,实际上并不是云原生的应用模式。

架构的本质是 降本增效
在百万架构师课程中讲了4+3的架构思维模型

  1. 业务需求 至简抽象 的 分析思维模型 (需求背后的真实问题)

  2. 哲学本质的架构设计思维模型
    1)CAP架构设计思维模型 (CAP的原理应用在不同的领域)
    2)BASE 架构设计思维模型

  3. 根据场景Balance的架构设计思维模型

  4. 适合的架构设计思维模型 ---- 适度超前的架构设计思维模型

归纳为:分析-设计-取舍-合适(关键是适度超前)

软件架构从 单体---》SOA,分层--》微服务、服务网格--》中台架构--》--》云原生 本质上讲 就是拆分 实现逻辑解耦到物理解耦 。那么具体到需求和场景(除了业务,还有人力资源,时间,成本等),在架构的设计上,都可以参考上面提到的思维模型。

单体架构 ( 性能指标RT要求苛刻场景、O2O)

金融的量化交易、高频交易,可能RT相差0.01ms级别也会导致重大的事故。

单体架构拆分时机的判断:1.多个业务同时请求同一个服务 2. 业务请求量增加 3. 开发效率低,迭代变慢。

垂直拆分即SOA架构,单体垂直拆分1个进程为多个物理进程。在拆分颗粒度上按照业务拆分,比如用户服务、商品服务等。也可以根据业务的特点进行API粒度的拆分。以最为普遍的用户服务为例,其里面包含 用户注册,用户登录,用户信息查询。当用户数量达到一定量级用户注册和用户登录相互影响时(也就是读请求和写请求相互影响),我们会进一步根据注册API和登录API划分服务。这个原则也适用于后面的微服务的拆分。

处理服务的拆分,可以看到数据库也按照业务进行了拆分,当单表数据量到亿级别时,还需要进一步进行分表的设计。但是对于分库分表的落地,除了我们在架构设计上感知外比如对MySQL数据库,也可以采用MongoDB,TiDB等NoSQL,NewSQL技术让他们完全替我们完成分库分表的实现。

上面拆分后的用户和商品还是单体,这里就可以根据需要进一步做水平拆分。

结合企业架构中的架构域划分,微服务架构 更适合作为一种业务架构,而不是软件架构。微服务的服务拆分,核心是解决业务颗粒度的问题。只是微服务的颗粒度更小,其组合变化的可能更多,但是治理的成本也更高。服务拆分按照上面的垂直拆分和水平拆分后,基本上也就是我们在为微服务架构中推荐的服务拆分方法了。当然对于业务拆分,你也可以采用DDD。

另外微服务和DevOps加速迭代,提高研发效率的最佳搭配。

服务网格ServiceMesh 通过拆的方式,把服务治理本身相关的部分拆出来,作为独立的服务进程,但是这个进程和原来的服务进程要求部署在同一台机器上(物理机/虚拟机/POD(容器))。通过统一的服务治理拆分,而且可以实现微服务定义中提到的多种语言模型的支持。

中台架构其核心是一种组织架构,在软件架构上可以根据实际情况,选择单体/SOA,分层/微服务 任意一种。也就是说 中台其实和 微服务没有必然关系,一定一定不要搞错了。

上述架构思维模型应对的我认为还是对外界客观世界的反映。实际上在很多系统中特别是大型复杂系统中,还有一个就是关于架构意图的思考。我理解架构意图更多是架构的设计者根据企业一些关键人的想法,在整个架构中注入的一些主观意图,以实现在一些业务划分上的战略构想。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值