建「中心」还是「平台」？
10年前在一个公司，公司里经常需要做线上活动。对开发来说，就是通过不同的活动页面进行注册、登录，之后会有一些个性化的小活动：领取小礼物、领取红包或者参加抽奖。
前端和后端疲于天天做各种换汤不换药的注册、登录。开发方式基本是把上次的代码拷贝一份，在此基础上做修改，来支撑新活动。大家就开会一起想解决办法解决重复开发的问题。大龄前端架构师说：「可以做工具自动生成注册、登录代码。」新生代的架构师说：「这个意义不是很大，应该做平台来解决。」10年过去了，现在我再回头想想。觉得当初应该建「中心」来解决。
首先明确一下「平台」和「中心」的区别。中心是个点，平台是个面。一般来讲，平台更大。中心是为了解决复用的问题，一般用在公司内部进行统一开发、统一管理、统一维护。比如业务上有「活动中心」；技术上有「配置中心」。平台可以对内也可以对外，按咱们「编程一生」群友的说法：是SaaS的。比如各种开放平台，还有网联清算等业务平台，各种交易平台。一般需要一些配套：用户注册、登录、权限控制等。
下面截图出于对群友信息的保护，隐藏了昵称和头像。
我们当时面临的问题，是要解决公司内部复用的问题，建立「中心」是合适的。当然，如果系统演进的好，以后把能力开发出去做成「平台」也未可知。但首先要是「中心」。
用「微内核架构」解决问题
我们当时遇到的问题，后端之所以每次都要参与开发是因为当时还是前后端不分离的架构。后端在注册、登录部分的修改主要是跳转的页面不同。现在都是前后端分离的架构了。后端只提供数据，流程之间的串联基本靠前端实现。所以后端只要有真正新功能的时候才需要开发，重复开发并不多。
前端对应每一个需求都是有一定的开发量的。但是对于这种重复工作多的，页面可以通过配置出来，而不用真正意义的开发。甚至可以通过低代码或者零代码的方式拖拖拽拽就把功能实现了。核心就是把原来的功能分成一个个小组件。
这听起来好像当下很多项目就是这么做的。怎样改造成微内核架构呢？
不需要再做什么了。这已经是一个微内核架构的项目了。不管对于前端还是后端，核心服务(内核)是注册、登录和做活动。具体产品和运营那边的奇思妙想，新的活动类型，可以视为插件。需要的时候开发出来插上，如果发现效果不好，要彻底弃用就拔下来。微小的核心服务+可插拔的插件，就是一个标准的微内核架构。
受到的质疑
之前和别人聊的时候，人家质疑时我说：你这样，安装插件的时候，服务需要重新发布，需要重启吗？
我说：需要开发，也需要重新发布上线。
人家说：需要重启就不是一个微内核的架构。
我心里知道他理解的不对，但一时没有想清楚他问题的本质，当时没有做任何的回应。现在想想应该这么来思考：
先看看标准的微内核架构代表：eclipse\Intelij idea这样的IDE(IDE,即Integrated Development Environment,是"集成开发环境"的英文缩写,可以辅助开发程序的应用软件 )工具。如果需要的插件是现在应用市场上没有的，也是需要重新开发的吧？开发出来就要上线吧？上线的方式可能只是打个包放到外部可以访问的平台上。但是IDE要集成插件引入之后也需要重启IDE吧？连微内核架构的经典代表IDE都是需要重启的，所以从是否需要重启来作为是否是微内核架构的标准是有失偏颇的。
微内核的本质是核心逻辑是有限的，可以维持相对稳定。其他功能可以方便的集成和拆除。它是一种思想，符合这种思想的都是微内核架构。面试时或者其他场景，你完全可以大胆的去说。
