市场是衡量一切的标准

“少年不知愁滋味，为赋新词强说愁，而今识愁滋味，却道天凉好个秋！”，这就是我对这些年我职业发展的比较贴近的比喻。

遥想当年，年少轻狂的我，凭借自己学习来的一些技术皮毛，一直标榜是架构师，然而实质上却是一些简单框架的整合者，同时也有一种认知的作为，在IT行业技术专家往往等同于架构师，至少在某一范畴区域内 ，该定理是明显是成立的，在之后的职业道路上，也构建起了属于自己的确有一套自成体系的论证与代码实现，仗剑行天涯，莽莽撞撞的过了很多年，技术一直在出新，我也一直在学习，然而，我却感觉自己学不过来了。回想之前的工作辗转，每次面试都是自己的一些技术优势夸大的强调，自己如何如何，对当时的主流的技术可以说是信手拈来 ......... 自我感觉良好，信心无限膨胀 ........ 浑浑噩噩的过着，也不知道当今的市场技术走向............

话题在转回到近两年，2014--2015年，我开始接触SOA架构，直到现在，我对SOA依旧处于认知状态，上帝关上一扇门，肯定会打开一扇窗，SOA么，也是分布式架构的一种，真是由于这一点的关联，让我开始接触并踏入分布式领域的范畴，从之前的 单机版 到 分布式，跨度有点大了，好比是 多重影分身术一样，眼花缭乱，我开始怀疑自身的价值存在，之前我所自豪的技术，到了分布式环境下，感觉没多大用处，仅仅能够解决了分布式模式下 针对某种业务场景一个点的技术解决方案。而面对整个分布式的技术体系支撑，我开始变得抓狂，不过还好，我一直努力在学习者，努力的读书，这里我也推荐一下大家 学习分布式的方法，学习分布式架构，首先关注的应该是 分布式的 格局，而不是一个技术点，例如 分布式系统面临哪些问题，这些问题需要如何解决，是否有更好的解决方案呢？等等，等这些理论性的东东变得让你认为很熟悉是，在找一些分布式下的技术点来看看，例如 分布式下常见的 消息驱动中间件技术，同步异步技术，ESB等，这些中间件都是为了解决分布式系统下的一些问题而衍生出来的技术，不到两年时间的学习，让我受益匪浅，但是这些知识 依旧不是我自己的，依旧是书本的知识，从几方面可以分析出来：
1、这些知识 我无法转化为自己的语言
2、我表述这些知识 无法成为一套完整的体系
3、表述的知识太专业化，不接地气（让路过的老大妈都能听懂 才牛Ｂ）
　４、理论有了，实践不足

　　现在，我感觉我在掌握一种方法论的东东，一种分析软件，架构软件的方法论，之前我所自信的那些技术在现在的我看来都不再重要，那些技术搁到整个软件架构的体系中，她们仅仅是解决一些细节的技术点，俗话说：做大事者不纠结，我也一度信奉这句话，一直沉迷与如何搭建一个好的分布式架构，需要用那些技术方案去解决分别是下给软件系统带来的负面影响，例如　分布式事务问题、长时间过程跟踪、事件驱动下的Ｑｏｓ等，如何把业务分解为分布式系统等，这就样子， 专注于这些宏观的东东，而很少关注一个技术点的细节。例如 分布式下的Qos 可以用 方法的幂等设计 或者防止消息重复投递 等机制实现，但是如何设计方法幂等、如何选用合理的中间件实现消息的防重复投递呢，这些技术领域的细节，缺无法有在多的时间学习，（不必当年了，学习如同打了鸡血），特别是家里孩子的出生，无形中压缩了很多学习的时间，每晚十点之前基本没有私人时间。都是分享给小孩的。

回归主题，写了这么多，我想我现在算是一个入门级别的架构师了，可是我再出去和别人去讨论的时候，却发现自己有带你不伦不类了，首先自己当年的技术优势 不复存在， 另外就是和对方谈论架构本身呢？对方又总是聚焦一些技术细节，一个是点的问题，一个宏观面的问题，两者并不矛盾，只是我感觉我 少了知音，也许我这两年来的学习已经是脱离市场了，市场目前可能更加需要的是 技术领域专家的 架构师 ，而不是真正的解决宏观格局的架构师。本年双十一，剁手了基本 技术点的书籍，《Redis实战》《R-MQ实战》等

一般公司招聘 需要的仅仅是能解决一些技术点的技术性专家，在我看来，很多人都从未站在架构的角度去看待架构，都是从自身的经验出发，搭建所谓软件架构。缺乏理论指导的架构，只知其一 不知其二。 如同我多年推崇的 责任链模式的架构，在行业内有专门的 规则引擎 去支撑，看完规则引擎 之后 在反哺我先有的 技术体系，好多可改进的地方，做事之前，理论先行，这一点要切记。

当你学习东西，在市场上很少有人可以与你对话的时候，说明你已经与市场脱节了，要不就是你在等待一个更加牛Ｂ的机会。千万不要学习成为　孔乙己－－穷酸　茴香的
茴字有多少种写法，不要做技术驱动型人才，要做业务驱动型人才，技术驱动的后果就是　　设计不足　　要不就是设计过渡。

　　　２０１５即将过去了，我寄托希望于２０１６～～～～～～ 不怨天尤人，相信市场会给自己一个合理的证明，市场是衡量一切的标准。