模块化的服务架构设计

我们大多情况下并不需要微服务，也许80%的情况，也许更多。

从微服务架构流行以来，越来越多的企业认识并开始采用这个架构来设计业务系统，有些甚至完全是不考虑业务规模和开发团队的规模。首先来说，微服务无疑是您实现大规模应用程序的最佳架构。但我们现在看到的趋势是，即使是中等规模的应用也倾向于使用它，它真的是必需的吗？大多数时候，答案是否定的。

虽然它是一个可扩展的体系结构，但它也有很多缺点。实际上，没有一个理想的解决方案是没有缺点的。这完全取决于需求和您对实施的满意程度。有的时候微服务所带来的复杂度甚至超过了项目本身

背景

本来想回顾下服务端架构设计的历史，但是写了又删，觉得都是老生常谈了，没有必要再展开来说。但是为了能说明为什么会有这样的设计，我觉得还是简略说下我的理解过程。

大约8-9年前吧，在前后端分离真正流行起来之前，React在国内还没怎么流行，Vue也没有出现。在那之前我开发了一套基于JQuery的UI插件（名字叫xjplugin），在当时这种完全前后端分离的方式已经算是蛮先进了，于是当时并一直到后来使用React或者Vue，项目中服务端开发所做的事情就是开发接口，并且主要是以经典三层架构为主，以下是一个简单的图例。

我们有时候也叫做它N层架构，因为真实项目中业务层会根据复杂度再切分为业务外观层和业务逻辑层，还有一些通用代码的专用类库等，不过都是一样的，这就是一个传统的单体程序架构。

后来我接触的业务是给第三方（其实是公司的其他部门）提供接口，本身是没有界面的。所以当时开发的代码都是面向服务的，但又不是传统的SOA。公司历史的接口协议都是使用C++的Socket服务。而我维护的部分则是以Java重写的实现。后来OpenApi流行起来后，这些接口部分要对外需要提供Http接口，于是又在此基础上通过插件加上Http调用的实现。由于当时用Java写异步和多线程调用的代码非常别扭，萌生了使用C#重写一个服务化开发的框架，那时候.NetCore 刚刚1.0 ，C#5 之后引入的await async的关键大大方便了编写异步逻辑，因为只有在业余时间来完成我的构想，所以第一个版本续续写了大半年的时间。

再后来我领导一个手机端交友App的开发工作，一开始开发团队规模只有10个人不到&#