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

写在前面好久好久没写了，最近刚换了工作，花了几天的时候熟悉了项目，接着就是功能的完善，随后就是对新项目的基础架构搭建。
看过Po主博客的都知道，Po主一直致力于推广.Net Core在微服务架构上的实践，包括从去年年底开始也正在写一本关于此类的书（目前还在写的阶段，不便公布）。换新东家的目的也是如此，公司是个集团公司，但楼主负责的项目还不是很大，So，微服务架构可能现阶段还无法实现。
但Po主一心向往微服务架构，所以我在搭建基础架构的时候，想到了一种过度架构方式，也不知道如何称呼，随心所欲称之为：单体服务架构（Single Service Architecture-简称SSA）
什么是单体服务架构什么是单体服务架构呢？总的来说，架构看上去类似于微服务架构，但它只包含了一个服务，我们的业务逻辑统统放到这一个服务来，简单画个图：

文章图片

怎么样，简单吧，我们来对比下eShop的架构图：

文章图片

如何，看出什么了吗？我们的架构去除了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 三层架构 【SSA-一种适合中小型企业的新型服务架构】可能你会问，为何不用三层架构呢？而且你的架构跟三层架构很像。
没错，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。

头大了吗?我们现在有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之路。
招聘启事