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 三层架构

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

没错，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之路。

招聘启事

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

联系方式

---

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