零散读了携程的架构，相关的感觉如下：
一、 软件工程领域没有银弹
“人月神话”中，没有银弹 这个理论，在今天是依然适用的，没有一招鲜能够解决所有的问题的架构，所有的架构都是循序渐进，都是需要满足于现实需求的。但是架构规划工作还是要提前看，至少能看到3~5年后的需求，技术不是一蹴而就的，但是准备铺垫工作是时刻准备的。
二、 对架构产品的理解
好的架构在技术上有很多的指标特征去衡量它，但是除了技术上的衡量，在团队上“架构师”们应该有更深的担当，架构的存在不仅仅是传术，更应该是布道。 而布道应该立足于痛点，立足于现实问题，立足于未来。而我们的团队感觉做的不是很好，我们当前更多的工作是在做术，我们引入了大量的“新”的工具，按照互联网已有的模式把这些工具搬迁进来，但是我们并没有有效的使用起来，没有意识性的把架构师辛苦创建的工具实实在在应用到一线中，导致大量的工具，最后都是停留到表面化，接入了、能看见数据了，然后就没了。
长此以往，当大量的架构产品使用还是停留于表面，一线使用不深入的时候，那这个产品的就会失去前进的动力，就是失去活性。
我想互联网公司之所以敢于开放很多优秀的软件产品，而不担心竞争对手把它学了去，更深层次的原因不在于技术，而在于他们组织内部已经有了针对这个产品非常深入的想法，他们知道产品当前问题是什么，未来方向如何，新的功能也能够迅速的得到验证反馈，有良好的产品氛围。他们晓得道在何处，所以他们不担心。 而当前别人熟知他们的产品，理解他们的道的时候，那这些竞争对手，最后都变成了同道中人，最终导致产品的用户越来越大，而自己也就水涨船高。
在《携程架构》中，看见了很多当前我们在实施的产品影子，LBS、CAT、DB Drvier 中间件、消息中间件等等，这些我想很多都是从开源的框架衍生过来的，在基础功能理念上我们觉得我们没有必要重复的造轮子，但是也不能仅仅是把轮子搬进来，然后接入数据上线能用就行了，所有的工具应该当成是一套产品，开发人员是用户，当前最为紧要的事情应该是想办法服务好自己的用户，让开发人员的效率能够提升更多，然后从用户中吸取更多的产品想法。
三、非架构工作的技术团队的启发是什么
多看看，多了解，多学习
当前的架构方向越来越是向去中心化的方向发展了，不管是应用、DB、运营全部都是向分布式方向发展；
分布式方向的软件产品百花齐放，当前中国暂时鲜有基础核心产品从头做起的，多是基于已有开源产品的二次研发的，理解了开源产品的用途，结合自己的需求重新改进，引入再消化；
了解了架构产品后，要善于利用这些产品，要能够通过这些产品提升我们自己的研发效率和开发质量，而不是敬而远之，按照要求接入完事；
分布式技术是未来的必然方向，在个人的技术窄上，需要多储备一些分布式软件的基础理论，那在使用新框架的时候能够更加的得心应手；
