好久好久没写了，最近刚换了工作，花了几天的时候熟悉了项目，接着就是功能的完善，随后就是对新项目的基础架构搭建。
看过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？