进入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

创作场景

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