SSA-一种适合中小型企业的新型服务架构


写在前面

好久好久没写了,最近刚换了工作,花了几天的时候熟悉了项目,接着就是功能的完善,随后就是对新项目的基础架构搭建。

看过Po主博客的都知道,Po主一直致力于推广.Net Core在微服务架构上的实践,包括从去年年底开始也正在写一本关于此类的书(目前还在写的阶段,不便公布)。换新东家的目的也是如此,公司是个集团公司,但楼主负责的项目还不是很大,So,微服务架构可能现阶段还无法实现。

但Po主一心向往微服务架构,所以我在搭建基础架构的时候,想到了一种过度架构方式,也不知道如何称呼,随心所欲称之为:单体服务架构(Single Service Architecture-简称SSA)

什么是单体服务架构

什么是单体服务架构呢?总的来说,架构看上去类似于微服务架构,但它只包含了一个服务,我们的业务逻辑统统放到这一个服务来,简单画个图:
image

怎么样,简单吧,我们来对比下eShop的架构图:
image

如何,看出什么了吗?我们的架构去除了Api gateway,去除了EventBus,把各个服务结合在了一起,形成了一个单一的服务,所以我称它为单体服务架构。

为什么需要单体服务架构

可能大家好奇,为什么需要单体服务架构(后称SSA)呢?如果大家了解过微服务架构的话,应该听说过康威定理吧,或者说听说过“微服务架构不是银弹”类似的话吧,概论就是并不是所有企业所有项目都适合微服务架构。但在技术热潮之中,中小型企业都想加入微服务的队列,但如何是好呢?我想SSA可能是他们在完成微服务架构之前最好的选择吧。

Po主在设计新项目之前,也一直困惑,如何为以后的微服务做准备呢?新东家是一家集团公司,业务体系庞大,团队开发语言也是众多,就近一个月的观察来看,运维、开发、维护的成本相当高,未来走向微服务架构是必然的,而且公司找Po主来的目的也是如此。

正如之前所说,目前Po主负责的项目比较小,投入的资源也不是很大,Po在经过前期调研之后,觉得目前并不适合做成微服务架构,经过几天的思量,Po主想到了SSA,去除了很多复杂性,但保留了微服务架构的可扩展,可维护性,也为以后转型做准备。

从SSA的架构图中,你可以清晰的看到,我们有很多的clients,正是因为如此,所以我们需要SSA,如果你的项目只有一个Web,那简单的三层架构就足矣。在SSA中,我们的Inside Api Management为我们的clients提供了所需的Api,类似于Api Gateway,但包含了我们所有的业务逻辑。在SSA中,你可以像微服务架构一样,抛弃数据层,当然我是不建议这样,你可以使用封装好的SqlClient或者Orm框架来协助,结合IUnitOfWork和Repository模式,这样你的数据访问就会变得很简单了。

SSA VS 三层架构

可能你会问,为何不用三层架构呢?而且你的架构跟三层架构很像。

没错,Po主的想法其实就是把三层架构中的业务逻辑层给提取了出来,把业务逻辑封装起来,并提供标准化的Api接口为其他Clients提供业务或数据。

但为何选择SSA而不是三层架构呢?

相信这里几乎所有的开发者都使用过三层架构开发,C端引用我们的逻辑层,逻辑层引用数据层,ok,这是因为我们只需要考虑到一个C端。就拿新闻系统举例,一开始你需要的只是展示新闻内容,一个前端Web足矣,我们叫Web1。但为了维护,我们需要一个后台管理,我们叫Web2,这时候已经以后2个C端了,这时候,你可以新建一个web项目,引用之前的业务层。可随着业务发展,公司需求一个手机H5的站点,我们叫web3,这时候你会再建一个项目,使用一些前端的框架的SPA项目,然后和web2一样,引用之前的业务层。

好了,现在你有3个C端了,我想想,大概1个中级的开发应该能够应付,如果,我说如果,你的这个维护人员离职了,呵呵,我相信没有一定经验的是接手不了项目,至少在短期内无法适应。

我们继续,公司要求需要一个适应微信端的H5,我们叫web4, 一个小程序,我们叫wxapp, 一个安卓:androidApp, 一个苹果:iosApp。
image

头大了吗?我们现在有4个web,3个app,一共7个前端,请告诉我用你的三层维护起来还好吗?当然,很多时候我们对接app的时候都会使用同一个api接口,算你5个C端吧。5个C端引用同一个业务层,同一个数据层,这时,你的一个逻辑出现了问题,你的一个数据查询出现了问题,Tell me!What would do you do? 我来回答下,我会在业务层修改这个问题,在数据层修改这个问题,然后5个C端发布下,这里还是考虑没有分布式,没有LB的情况哦。Bro, Are u OK?

你应该明白我的意思了吧,如果你使用SSA的话,你其实只需要更新这个Service,我们的发布也只需要更新这个Service,其他的C端并不需要改动。而且当你的Request和Response参数不变的情况,我们统统不需要重新发布C端。

SSA 和三层架构的对比:

/ SSA 三层架构
开发的角度 注重service端,前后端可完全分离 全部都要注重,前后端无法完全分离
部署的角度 多了一个Service Site 少一个Service Site
维护的角度 如果只改了service,只需要一个发布 只要改动到业务逻辑层,我必须全部都要发布
硬件成本的角度 可能多一台服务器或者一个集群,也可以不用多,多一个站点即可 维持不变
人员成本的角度 自己想吧,老板们 运维、dba、dev、老板

SSA的优缺点

SSA 的优点

  • 是一个集经典三层架构和微服务架构一身的新型架构。
  • 适合中小型企业和中小型项目。
  • 在维护上和微服务架构一样便利。
  • 在成本上却和三层架构一般。
  • 不需要EventBus。
  • 不需要熔断,因为你只有一个。
  • 在开发上能够快速迭代。

SSA 的缺点

  • 依赖度太高,所有依赖都在一个Service上
  • IO,因为只有一个,必须考虑到IO,当然也可以集群
  • 无状态,跟微服务架构一样,service必须无状态
  • 可能依赖多个DB
  • 欢迎补充

写在最后

其实还有很多话想说,但很晚了,后面还会继续发文跟大家一起探讨这个架构。

Po主是一个喜欢天马行空的人,但这一次,Po主正在把它进行实践,而且基础框架已经搭建完成,不久之后将会正式上线经受考验。

Po主最近正在开发一个基于.Net Core的服务发现项目,名字就叫“发现者”,可是实在太忙了,只完成了一部分,如果有意参加的,可私信我。

另外Po主需要几位志同道合之士,一同来发展,原本想要一个中级,但现在中级的价码有点高,Po主承受不住啊,欢迎校园刚出来的或者初级,Po主有信心带你们走上.Net Core之路。

招聘启事

  • 会.Net Framework 4.0以上,.Net Core尤佳
  • 会一种ORM
  • 懂得什么叫Web Api
  • 爱好分享,爱好开源,爱好写代码
  • 月薪10K-20K 论能力
  • 地点:上海-吴中路
    我觉得招人启示不用太花俏,大家有相同的理念,投缘即可。不过Po主有一个其他重要的要求,写漂亮的代码,Po是一个见不得Bad Code的人。

联系方式


邮箱:james@taogame.com
QQ:785418
微信:jamesying1
QQ群:376248054
应聘者请注明来源:cnblogs-应聘