如何确立架构的目标是面向运维？还是面向开发？

进入 2017H2 开始，“夜跑 + 晨读” 的工作模式开始变得不够牢固，“夜跑” 还行，无论多晚到家基本都能跑个 30min 以上，“晨读” 却有点懈怠，我暂时把它归功于 “天气比较热” 吧，至少能够让我的内心找到一些平衡。

话题的由来

为了调节口味，近期的晨读从原有的 村上春树大选集 改为了技术类公众号碎片化浏览，由于工作的需要，在选题上着重对「分布式数据库」的开源框架或架构信息进行拜读，在阅读完「当当开源 Sharding-jdbc，轻量级数据库分库分表」后，结合近年来在平台化演进过程中的点滴进行了思考

先从几个常 ‘听’ 疑问开始：

提疑问：“为什么非要自主研发？”

我觉得：“下载 Redis 用起来就行了呀，集群及高可用方案官方都提供了，很成熟”

提疑问：“为什么要增加代理层？”

我觉得：“将 SDK 再次封装下，并把配置外移，便于维护就可以了呀”

提疑问：“为什么要集中化管理，环境统一？”

我觉得：“违背了分布式的基本原则啊，当然应该‘逐一部署，各个击破’啦”

提疑问：“为什么总要变更 SDK？”

我觉得：“能不能你们升级别影响我们？测试没资源，而且自动化覆盖率也不够，没法做到全面回归”

这些疑问和见解，在许多公司的平台化演变过程中或多或少的出现过，当然，纯靠 “堆人+堆机器” 打通关的也不在少数，甚至一年之间系统重构过 2-3 次的也不在少数

在 「GTLC - Open Space」资产配置时代来临，平台化演进中的问题与挑战 的文章中我提过，互金业务背景的 IT 演变，多半运行在 “先污染，后治理” 的轨道上，区别无非就是「按技术岗位的横向污染，还是按照业务条线的纵向污染」罢了。

面向运维，还是面向开发

当今 DevOps 可以说是如日中天，只要 IT 技术话题中不包括 AI、大数据、云或 DevOps 这样的热门词语，那还是闭上嘴巴，免得遭来白眼；

活在当下，正视前方

大部分从事于以业务产品为核心竞争力的企业的小伙伴们，还是需要时常的低下头，摸着自己的前胸问问自己 “本月的目标实现了吗？是否偏离了初始的目的？”

就像近期我们团队时长挂在嘴边的一句话 “这日子还要过下去是吗？先把把你那些飘在空中的东西搁一搁行吗？”

这绝对不是简单的 “问题驱动” ，“聚焦型人物性格”，甚至是 “不懂规划与掌握未来”，规划人人会做，关键是如何能够 「在仰望心空的同时，坚定不移的脚踏实地」，所以需要结合 “自身的业务特点、历史发展历程、技术文化价值观”之后，再来其他的

原因 - 选择面向运维（策略）

• 技术松耦合：轻量级 SDK，把更多的逻辑与规则放到代理层实现；

• 产品化理念：「缓存系统」与 「支付系统」，都是一种产品，只是服务对象不同；

• 快速化迭代：每个系统之间都能够独立发布，就算大版本升级也尽量互不干涉；

• 快速化部署：当出现故障、冗余或性能需求时，能够更快、更灵活的变更规则与逻辑；

理由 - 难以面向开发（痛点）

• 发布模式：暂不支持「持续集成、持续交付、持续部署」；

• 业务线多：资产配置时代，每类产品都是一套完整的系统，如保险、公募基金、私募基金、以及……；

• 测试方式：黑盒测试占比极高，自动化测试正在路上；

• 历史累计：从一个程序，变成一坨程序，变成一大坨程序，连用的 JDK&第三方包都不一样，更别说开发框架了；

• 资源投入：人力资源与时间资源都紧靠业务需求，污染的速度大大的超过治理的速度；

结束语

上面的「原因」与「理由」，只是一个总结，大体的思路其实在 「GTLC - Open Space」资产配置时代来临，平台化演进中的问题与挑战 中也提到过，只是视角不同罢了，如果遇到相同的业务场景与处境，大可直接套用

不过话说回来，在我的脑海里，一直认为分享更多代表着一种经验的传承向往，为什么说是向往？因为你表达的是你自己，和别人没有半毛钱关系，大量的事实证明，绝大多数的经验只能用来借鉴、开脑洞，如果直接拿来就用，那恭喜你，你又为自己挖了一个大坑

本次文章的废话显然多了一些，把他理解为唠叨也行，称述现实也罢，希望这些话给大家或是我自己一种启发，一种标记，一种沉淀……

本文转载自头哥侃码公众号。

原文链接：https://mp.weixin.qq.com/s/LSmpWvpcXbqOVOrXUvZzIA