本文为稀土技能社区首发签约文章，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 云渠道化的优点

当企业具有自己的云渠道，所带来的优点会十分多，包括且绝不限于：

• 招引人才
• 利于推行企业
• 资源统一管理
• 产品生命周期规范化
• 研制效率提高
• 运维本钱下降
• 提高服务的稳定性，容错性
• 自动化的运维、灰度
• 利于完成快捷且强壮的服务监控
• 云原生带来的强壮的扩展才能

三、架构计划的场景

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

• 自我定位明晰的单体架构
• 目标明晰的微服务架构
• 企业自有云渠道化

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

可是关于细小型企业而言，这三种方法是需求技能人员去着重考虑的，依据不同的事务场景、不同的体量去考虑不同的架构方法。

• 单体架构

  依据第三方开源体系，或公司沉积的单体架构，快速的完成事务逻辑，且并发量较小。十分合适短期，快速开发的项目。随时单独布置，关于其他体系和事务场景没有依靠。

• 微服务架构

  事务有明晰的鸿沟，可以明晰的抽取单独的服务，且该服务具有必定的事务代码量。一起针对某个服务，存在大量并发，抽取后利于体系的稳定性。更加适用于具有中台的体系环境，环绕该中台组建自己的微服务网格。

  在缺少自动化运维的加持下，过多的服务将会添加必定的运维本钱。

• 云渠道

  公司的事务具有必定的体量，且大部分体系是公司的自有项目，依托于自有云渠道，可以将各个项目动态、快速的布置。完成项目的统一管理，运维。
  依托于云渠道，项目将不再局限于“单体架构”或“微服务架构”，无论何种方法，都可以在云渠道以最合适的方法进行展示。

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

四、总结

前面讲解了在细小企业傍边存在的几种架构方式，从原始的单体架构，到变形的微服务，再到云渠道化的场景，每种架构都有其存在的含义，如何更好的发挥它们的作用，是作为开发人员需求决议的。决议的正确与否，将会影响企业，项目的许多环节，所以，在考虑项目完成计划的时分，要稳重挑选。关于技能的演进，也需求作为企业推动的方向。

后边的文章，将会详细探究细小企业架构演进的计划，经过项目案例去完成一个从零到一的过程。

---

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