本文为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！

一、背景

为什么想要写这样的一篇文章？主要是基于我个人的从业经验而言。我本人在哈尔滨这座软件行业并不发达的的城市，企业的软件架构并没有一个快速且完整的过程，并且没有主动接触新鲜技术的想法，或者说没有一个明确的思路。即使想要有这方面的尝试，也只是企业内部的某个程序员的个人行为，没有形成体系化，也很难被领导重视。当然，也有些公司会积极的尝试新技术，但也仅限于基本过时的“微服务”这样的概念，然而这样的尝试，也许将会带来大量的重复工作，还有人工成本、资源成本的浪费。

觉得我说的没有道理？下面咱们一起来分析下。

二、微小企业的项目架构

关于微小企业的项目架构，主要分为三个方向：

• 单体架构
• 微服务架构
• 云平台化

没错，这就是哈尔滨的软件公司的两种架构模式，当然也有一些公司，因为技术leader来自一些技术领先的公司，会积极的推进公司软件的自动化，容器化等。

2.1 单体架构

单体架构，是每个后端程序员相当熟悉的词汇吧。现在常见的单体架构，以java为例，依托于springboot实现快速的代码开发，部署，对比于早前的tomcat环境，可以说已经进步了很多。

即使是单体架构，我也会将它们分为两类：

• 不思进取的单体架构
• 自我定位清晰的单体架构

2.1.1 不思进取的单体架构

企业认为发展业务才是王道，技术只是辅助手段，能用即可。

对于这一类公司还是有不少的，手握N多年前的SSM（spring + springmvc + mybatis），还在使用的津津有味。当然了，对于一些小型公司的项目而言，这类技术没有任何问题，但是对于程序员的提升可以说是零吧。最终会导致以下的问题：

• 留不住技术人员

  持续使用这一类的技术，将会很难留住公司的绝大部分程序员，毕竟靠技术吃饭，不可能一招鲜吃遍天的。每一个程序员都想尝试新的技术，提升自身能力，这样日后才能创造更大的价值。技术都会随着时间被淘汰，更何况是使用技术的人呢？

• 很难引入优秀的技术人员。

  程序员的眼中，还是有很深的鄙视链的，不管你信不信，它就在那里。拿我个人来说，让我回去使用SSM进行开发，我甚至都不会去面试。2019年，我经历过一个京东回来的同事，他对于我们当前使用的技术存在着深深的鄙视，无论领导多看好他，答应给出远高于哈尔滨公司水平的薪水，都不能将他留下，原因就是“你们用的技术，在几年前就被我们淘汰了，这不是钱的问题”

综上所述，只要企业是靠技术去吃饭，那么对于新技术的接纳和提升是必然的，利大于弊。

2.1.2 自我定位清晰的单体架构

什么是自我清晰呢？

对于公司的技术水平，和产品的业务定位，有清晰的认知。不会通过复杂的方式去处理简单的项目，比如为了使用微服务，将原本简单、清晰的项目强制拆分为多个服务。

使用最简单的方式去完成项目的研发。其实服务的拆分是一种系统优化的方式，当你的单体项目能够胜任当前的工作时，为什么要去做无谓的优化呢？

优化一定是在存在问题的时候，才进行优化，想的越多就会产生越多的风险。

对于某些单体项目，部分微小公司采用的方案就是通过开源项目进行扩展开发，比如常见的“若依”等管理系统，基本能够满足简单项目的需要了。快速，便捷的完成项目，才能将成本降到最低，效率却是最高的。我认为这才是快速产品迭代的基础，盲目的微服务化只会适得其反。

2.2 微服务架构

目前微小型企业的“微服务架构”种类，最常见的还是以java开发为基础的两个派系：

• SpringCloud
• Dubbo

以上两种服务框架配合Nacos进行使用。

当然新兴的GO语言，也是目前后端的一个方向，但是对于微小企业来说，成本过高。

就我目前的体会来看，在微小企业的微服务架构也存在两种情况：

• 病态化的微服务
• 目标明确的微服务

2.2.1 病态化的微服务

何为病态化的微服务？

换句话说，就是为了微服务而去微服务。我经历过的一家企业就是如此，毫不夸张的说，那是我经历过的服务数量最多的一个项目，却存在一个名不经传的小公司里面。

起初引入微服务是为了给领导彰显公司的技术能力，表示咱们的技术也是紧跟前沿的，慢慢的就变味儿了。随着领导的想法越来越多，项目的新功能越来越多，每多一个功能，就增加一个服务，到最后整个服务数量已经达到了20多个。

你以为这就完了吗？第二年技术领导又开始引入了“DDD”的概念，在每个微服务上继续引入“DDD”的架构，将每个服务拆分成以下的方式：

• 基础模块intr层
• 页面ui层
• 应用app层
• 领域domain层，内部抽象聚合根

不说项目的复杂度成指数级增长，那也差不多了。然而领导始终没有考虑到以下的问题：

• 很多服务的根本都是相同的业务模块，真的有必要放在不同的服务当中吗？

• DDD原本就是通过四层架构去梳理业务代码，而目前每个微服务当中的业务模块只有一个，“DDD”存在的意义又在哪？

• 对于诸多的服务，是否考虑过硬件成本的问题。

• 是否理解微服务当中所谓的“三高”是什么？

  • 高性能：服务的调用，真的比单体性能高吗？
  • 高可用：这么多的服务，保证高可用的复杂度是否能够承受？
  • 高并发：高并发对于咱们的产品而言，真的是存在的吗？

• 运维成本是否考虑过？人工还是自动化？

• 内网环境下，部署微服务的网络环境问题是否能够顺利解决？

• 系统升级的时长问题？比如公共组件的升级，所有服务通过人工部署的方式需要多久？

• 性能监控与链路追踪问题？微服务的排错是比较复杂的，必须要有一套监控体系支撑。

综上所述，包含但不限于这些内容，我觉得可以将这个系统彻头彻尾的称为一个病态化的微服务架构。

2.2.2 目标明确的微服务

目标明确的微服务架构其实很简单，也很纯粹。业务代码有必要、且只做相关的业务处理，并且会作为必要使用的服务，就可以抽取为一个单独的服务。

比如我们经常能够见到会被抽离的服务：

• 用户中心：不属于任何模块，服务于各个业务之间。

  在不同的系统当中，都会拥有自己的用户体系，除了用户的基本信息等等，可能根据不同的业务还会拆分成：

  • 用户积分
  • 用户标签
  • 用户画像

  以上的体系，都归属于用户，在实际数据量，并发量不大的情况下，我们仍然可以将它们放在一个服务当中，通过“DDD”的领域进行划分，相互之间以事件的方式进行暴露和调用。这才是具有明确目标的使用方式。

  如果不使用DDD的情况下，我们仍然可以使用模块化“moudle”的方式进行划分，通过子模块的方式对各种业务进行隔离，这也是常见于各种开源组件的实现方案。

• 登录门户、认证：基于用户中心的前提，将公司产品的登录门户，统一认证进行抽离。

  抽离出来后可以服务于公司的各个系统，通过统一的登录门户进行登录和认证，以回调的方式接入业务系统。除此之外，其内部还可以聚合一些具体的权限验证：

  • 用户角色

  • 用户菜单

  • 角色权限

    • 菜单权限
    • 按钮权限
    • 接口权限

综上所述，我认为这两个例子就是较为明确的微服务拆分方案，总结来说：

• 具有明确的业务概念，自成一系
• 围绕自身的业务概念，衍生相关的业务逻辑
• 聚合且不臃肿

满足上面的要求，起码会成为一个健康的微服务架构。

2.3 云平台化

微小企业做云平台化非常少见，但是只要开始实践，慢慢的将会体会到其中的乐趣。

2.3.1 云平台化方案

常见的云平台化也分为两种：

• 购买云平台产品
• 搭建自有云平台

两种方式的成本其实都不小，但是区别在于：

• 购买云平台产品是需要持续续费的，但是有专门的客服帮你解决问题，随着时间推移，成本将会持续消耗。
• 搭建自有云平台，前期主要花费在硬件成本，以及人工搭建成本上，一旦成功，将会是一本万利的。

我个人推荐微小企业采用搭建自有云平台的方式，主要出于两点考虑：

• 成本较低
• 资源可随业务场景扩展
• 成功后，拥有很高的自由度
• 对于有安全要求的企业，可以将公司的知识产权掌握在自己的手中
• 云平台的搭建，对于软件开发的流程化将有质的飞越。

云平台建设的过程是让人头痛的，包含但绝对不限于以下：

• 硬件网络环境
• 容器环境
• 基础设施搭建

上述的每一个环节都不简单，其中的细节问题更是数不胜数，还有各种预想不到的问题在等着我们。

2.3.3 云平台化的好处

当企业拥有自己的云平台，所带来的好处会非常多，包含且绝不限于：

• 吸引人才
• 利于推广企业
• 资源统一管理
• 产品生命周期规范化
• 研发效率提升
• 运维成本降低
• 提升服务的稳定性，容错性
• 自动化的运维、灰度
• 利于实现便捷且强大的服务监控
• 云原生带来的强大的扩展能力

三、架构方案的场景

通过前面大篇幅的叙述，本文详细介绍了目前存在于微小企业的各种“服务架构”场景。其中我比较推崇的是：

• 自我定位清晰的单体架构
• 目标明确的微服务架构
• 企业自有云平台化

上述的三种方案恰恰是当前服务架构演进的一部分，从单体、到微服务、到云原生。

但是对于微小型企业而言，这三种方式是需要技术人员去着重考虑的，基于不同的业务场景、不同的体量去考虑不同的架构方式。

• 单体架构

  基于第三方开源系统，或公司沉淀的单体架构，快速的实现业务逻辑，且并发量较小。非常适合短期，快速开发的项目。随时单独部署，对于其他系统和业务场景没有依赖。

• 微服务架构

  业务有清晰的边界，能够明确的抽取单独的服务，且该服务具有一定的业务代码量。同时针对某个服务，存在大量并发，抽取后利于系统的稳定性。更加适用于拥有中台的系统环境，围绕该中台组建自己的微服务网格。

  在缺少自动化运维的加持下，过多的服务将会增加一定的运维成本。

• 云平台

  公司的业务具有一定的体量，且大部分系统是公司的自有项目，依托于自有云平台，能够将各个项目动态、快速的部署。实现项目的统一管理，运维。 依托于云平台，项目将不再局限于“单体架构”或“微服务架构”，无论何种方式，都可以在云平台以最适合的方式进行展示。

  对于做外包项目的公司，云平台的含义相对较小，体现在产品孵化的环节会多一些。

四、总结

前面讲解了在微小企业当中存在的几种架构形式，从原始的单体架构，到变形的微服务，再到云平台化的场景，每种架构都有其存在的意义，如何更好的发挥它们的作用，是作为开发人员需要决定的。决定的正确与否，将会影响企业，项目的诸多环节，所以，在考虑项目实现方案的时候，要慎重选择。对于技术的演进，也需要作为企业推动的方向。

后面的文章，将会具体探索微小企业架构演进的方案，通过项目案例去实现一个从零到一的过程。

---

不知道各位同僚正使用的架构，属于哪一种？**病态化