看了看以前的记录，感觉很久没有写设计方面的文章了，工作久了，总会有些心得体会，以后回首往事的时候，不希望只是想到我工作的N年，长期奋斗在一线，应该形成自己的方法论，正确的方法论能够指导我们走的稳，走的远。今天开始，我会把工作中的一些场景的思考发出来，有些系统的设计可能并不完美，但这不妨碍我们去使用，反思，平衡成本和优势劣势的关系，下面开始。
现实的开发中总给我们一些倾向，一谈系统就高可用，高并发架构，其实现在架构都很成熟，反而日常的运营工作更重要一些。即：系统不仅仅有系统架构层，还有业务层，今天想说的是以前我做的一个基于json块配置的业务后台模块的设计思考。
需求背景：七八年前，我们的后台配置基本是，一个模块一个数据表。每个模块的数据量都不大，大量重复的工作造成工期的延迟交付。特别是有些行数不多的多维内容配置，往往需要几天去搞后台，而来自老板产品的时间压力让我们需要提速开发时间。于是对于这种情况做个简单通用的配置就显得非常重要。鉴于每次的数据结构层次都不相同，于是使用的json的模块。
优点：适合小型结构不一的多项配置，灵活多变，格式比较简单，比较通用，除非特别排斥，从根本上不想用的用户，可以嵌套，支持 列表，map，int，stirng，boolean 等多种类型，尤其是效率高。
缺点：比较简陋，体验下降。如果有时间，还是希望开发者更合理的设计自己的功能，进行定制化开发，让产品操作更简单。
基本的设计思想：
这是这个功能的雏形，能做到这一步只是有了基本的设计能力。如果只是满足于上面简陋的方案，那么肯定会出乱子，如数据错了怎么办，数据超长了怎么办，修改了一大段不知道修改了啥，多人修改刚保存的部分数据会不会被上线等等。于是我在这个雏形基础上进行了不断改进：
1.数据格式化和检验
功能模块应该对用户的输入进行最基本的校验，如长度，格式是不是正确等。配置数据块是保存在mysql数据库里，选用的字段类型是text，而text的长度是64k，所以我们限定单个配置长度要小于64k，看似很简单的限制，之前确实在其他公司的应用场景中出现过因为没有限制大小出现过超限的情况。而检测格式，我们后端保存的时候对数据进行json_decode 再json_encode的操作后进行处理，如果是一个有问题的数据块，那么是不会写入数据库的。前端页面里，我们会对已经填写的数据进行格式化。ES6中JSON.stringify 和 JSON.parse 两个函数是个不错的选择。
当然也会进行简单美化数据。通常采用空4格的方式。
之前考虑过大段文本的方式是不是可以改进，观察了一段时间发现下面右侧的方式不如左侧数据结构直观，而且操作起来，点击的次数增多。数据填写到理解变的复杂，也就没有过多关注编辑器的问题。
2.权限保障
多人会用到这个模块，权限怎么保障，以前的功能权限只做到了功能模块阶段。这个要做到每项的权限。于是多了一个可编辑人员的输入项，即：每个item里增加一个可编辑的人选项，只有拥有模块权限和配置项权限才能编辑此配置项里的内容。这里还要设置一些超级用户，防止有权限的同学离职，而导致其他同学无法编辑的问题。
添加/删除的权限，这两个权限比较特殊，一般都是保留在开发者手里，不开放给用户的。
3.描述说明
现实中观察，有很多开发者开发的功能只是一个增删改查的功能。缺乏功能的基本描述和必要的说明，这是可以改进的。我们可以在列表的正上方加些说明性的文字，帮助用户方便使用功能。每个item里也都会预留一个多行文本字段去说明配置的背景内容字段解释等相关信息。
4.多人协作
这个功能采用了两个分区，即：用户编辑区和待发布区，分别对应两张不同的数据表。只有从用户编辑区，进入到了发布区，才能发布到线上。
5.页面布局
之前的系统，发布按钮放在了列表的下面，用户往往看不到，不知道有发布这项，经常有同学使用的时候造成误解。经过实验发现右上侧蓝色按钮是最醒目的。
当然也有同学开发功能放在了左上侧的，看着很丑，不如右侧明显。后来的若干个功能也都是这个布局。这是UI层面的内容，看似简单，其实不同元素放在不同的位置上体验效果还是有所区别的。
编辑页面亦是如此，经过无数次的研究保存放在第一屏右侧的位置，比最下面的位置能极大的改善用户体验。
6.比对&发布
这是这个模块的最复杂的地方，一般的功能只是点击发布，然后出来个确认弹框，点击就发布了。我们的功能是不能这么设计的。用户修改了重要的数据，在上线的时候需要知道自己改了哪些字段，从什么改成了什么。设计这部分的逻辑，是先把数据转成的ini的扁平化数据的格式，然后和线上的配置进行比较。
整体功能分成：操作区，信息展示区，比对展示区。这个功能应该是这里面的比较重要的模块吧。特别是比对展示的内容。
7. 重复发布
用户有时不确认自己是否发布成功即使有返回信息，会多点击几次发布按钮，难道每次都要重复一系列动作么？重复发布的检测的必要性就显得尤为重要。即：
(1)比对环节，如果没有新的发布内容是要有醒目的提示，和隐藏下一步发布按钮的，如上面示图。
(2)程序内部写入环节比对，有些开发者开发的功能可能没有1的步骤，那么统一写入函数里面就需要做些逻辑，包括数据格式的合法性，即到底是不是个期望的目标样式，为空是否可以发布等。另外会和线上的配置文件进行比对，如果一致则不进行处理，返回错误。
8.发布的备份
发布的备份没有和6中发布的逻辑设计在一起，做的比较独立。这个功能采用的是变更后的文件备份策略：主要是两点内容：1.线上文件的备份，2.备份行为的记录。
9.配置再发布-回滚
有了8中保存的备份配置文件的内容，我们就可以做一键回滚了。业务场景：当之前发布的内容出现问题的时候，我们希望快速的回滚，将最后一班正确的配置推送到线上。这是一个小众的低频保命需求，平时不一定能遇到。首先要解决的也是权限，前端入口检测+后端程序内部权限检测。
10.灰度发布
也看过一些配置中心的灰度发布机制，一般都是运维层面的灰度发布，按照机房逐步下发配置。做灰度发布之前要了解一些规则：
1.灰度发布不能替代测试，更不能不测试。
2.灰度发布的解决方案不唯一，可以是业务层面上的，也可以是业务底层的，或者系统级的，根据应用场景使用不同的方案。
3.灰度发布的尽头是全量，如果可以按照功能能独立发布，一个功能全量后，应该是所有的场景都是一样的。即：要么一部分实验组处在灰度发布的实验里，要么全部在最新功能里。不存在实验组落后的情况。
当然，每种设计方案都有其局限性，开发这个系统也是，不是让开发者偷懒，让非技术人员去填写大段的json数据是个不道德的行为，初衷更多的是为了节约时间，牺牲一些体验，让开发者按照一定的思维先实现功能，快速上线。后期即使修改，也应该让产品等非技术人员只改0 -> 1，换个字符串等操作，而上线比对，灰度发布，再三确认也是必不可少的环节。
最后总结，日常的开发不都是高并发，大流量，大数据，造自行车的也是高级工程师。一辆车好不好用要看使用场景，用跑车去开山路，同样玩不转，项目参与者还是应该秉承慢下来的思维去精益求精的做事，只有一步一个脚印的走好每一步，最后才走的稳，走的远。
上面是我对所做的一个功能的复盘思考，有时很难衡量它的好与坏，高雅和低俗，一个后台也好，一个项目也好，不是靠一个功能起作用的。一个好的服务项目应该是套组合拳，即：多功能联动共同撑起业务这片大树，之后会继续总结～
