ABP VNext微服务架构系列(一) 架构的演变史

ABP VNext实操落地微服务架构系列(一) 架构的演变史

一 、聊聊单体架构至今的演变史

1.最初公司的业务比较单一且访问量不太大,单台服务器就能支撑整个公司业务的时候

     我们会将数据库,web应用和接口统一部署在一台机器上(或者数据部署在单独的机器上)
     架构图如下：

2.随着访问量的变大,一台接口机器不足以支撑,于是通过增加接口的机器来解决

3.虽然接口层做了负载均衡,但是出现了新的问题,数据库扛不住了,于是在查询方便又做了一系列的更改

 在数据库层面根据实际场景通过主从、读写分离、分库分表来减轻数据库的海量数据问题及高并发访问问题。
 在接口层中间加入一层SLB缓存,避免大流量打崩数据库

4.虽然抗住了与日俱增的流量问题,但是发现每一个接口实例都干着一模一样的事情,于是在业务层面进行了一次拆分(以电商业务来举例)

注:此处省略缓存和数据库集群高可用.

1. 此处按照业务拆分成物流业务、天猫业务、商家业务三个大模块,分别处理各自的业务一起提供相应的服务来组合业务.

2. 这样拆分下来形成的SOA架构.不同的业务团队只需要专心处理自己的业务,不同的业务模块之间可以通过WCF来进行数据交互.松耦合,互不影响.

3. 当然省略了其中的部分逻辑的处理.因为SOA是面向服务式编程,架构越复杂,问题就越多.服务治理,服务发现,分布式事务等等.(当然这个不是本文介绍的重点)

5.虽然SOA细化了业务,但是每个业务之间还是会有很多重复使用的东西

1. 随着.net core生态的越来越活跃,微服务和DDD的思想也就慢慢被扒出来了,加上.net core结合起来很是不错.

2. 对整个项目进行更细化的拆分建模,保持足够细的颗粒度.而每个拆分的服务都是独立的.

3. 将公共的部分抽离出来,开发人员只需要关注自身的业务逻辑实现,对于和业务不相关的内容则不需要关心.

4. 部署更是方便,因为.net core 跨平台,可以很好的和 k8s 结合起来.

6.最终形态ServiceMesh---->Side-Car(边车模型架构)

1. 对于这个架构作者没有实际使用过,只是用Dapr做过一些简单的demo.所以功能优劣作者就不乱发言了.

2. 感兴趣的朋友可以去看看Dapr,因为Side-Car模型主要也是为了解决一些微服务架构中的痛点,进一步的抽离中间件.但是对一些公司来说,好像实际落地还比较困难,所以建议了解一下即可.

7.总结 (个人心得,如有错误欢迎指正！！)

1. 演变史只是作者根据个人经验做的一些比较简单的总结,具体每个阶段都还有很多很多可以扩充的地方和会遇到很多很多的问题.
2. 但是对作者来说,写这开头文章的目的不是为了介绍架构演变史,只是为了将ABP VNEXT+微服务架构出现的前生背景介绍一下,做个铺垫.
3. 本系列文章将会从零搭建一个ABP VNEXT的微服务架构.中间也会介绍一下ABP这个框架和其他关联的内容.