e4682431aaf5

硬技术的确远比大道理重要。那为什么大多数人硬技术做得差，原因就是多、难、吓人；一来让人容易放弃，二来真的难、学不下去。所以咋办，不是一句话坚持学就完事的；需要一一解决。多：掌握原理、触类旁通，化多为少；难：提高效率、看好书好教程、由浅入深，还不行就先放弃，找机会实操后再学；吓人：心中无敌无敌于天下、别管别看吓人的文章。

你该关注“硬技术”还是“大道理”呢？

现在的微信公众号已经呈现出“泛滥”的趋势，得益于这两年的“内容创业”大潮的指引，很多人先后投入到了这个领域中。于是，我们会看到，每天在朋友圈大家都在不停转发各式各样的文章，千...

张龙的思考

334 1 1

e4682431aaf5

吐槽一下：
软件领域大部分技术本质是极其简单的，这一行里新技术层出不穷名字又爱唬人，很多大佬又喜欢写些技术文章，把简单问题复杂化，导致很多新人被各种吓、觉得八辈子都学不完。

举例，我不同意老师你的这一句：
Spring Cloud所涉及到的技术点与功能是极为庞大的

我认为：
Spring Cloud所涉及到的技术点与功能很多很杂，但都极其简单，不庞大很渺小；这些个技术点加起来只干了一件事，让分布式服务维护（服务治理）起来更方便高效，明细如下：

分布式开发与部署：因为一个服务有很多节点（机器），所以需要搞一个可视化的发布部署管理系统，部署快速方便点
配置管理：因为想改配置，机器太多不可能人肉重启，所以需要一个动态生效的配置系统，上这个管理系统上一改，所有机器都能快速生效
网关路由：对用户比如app提供的http接口，由于后面提供了很多服务，为了让各种用户使用简单，提供统一的网关层，就干一件事，根据比如url来转发请求到对应的服务
熔断：分布式服务通常流量比较大，万一突发事件，流量再猛增几倍，可能真个系统就挂了，所以需要搞一个预警，流量达到一个峰值就降级，服务直接返回空
负载均衡：服务分布式了，万一某个节点量很大，别的节点很少，量大的节点就会挂，所以需要一个让流量均衡打到每个节点的玩意
日志处理：服务分布式了，不可能挨个登陆机器去查日志，最好有一个集中收集可查询的系统
追踪：一个请求需要十几个服务处理，最终结果失败了，要查原因，不可能每个服务挨个去看日志，需要一个穿通整个流程的玩意
数据处理：略
服务注册与发现：服务有多个节点，上新下旧，咋通知客户端，需要一个玩意搞这个
安全：略

回过头看上面这些所谓的庞大的技术点，每一个都很渺小，本质上都极其简单且不重要（跟核心业务流程比较），没有这些，分布式服务也能跑，只不过维护起来得累死，为了不加班为了不累死，大牛们各种“投机取巧”搞出一堆小玩意挨个解决各种维护问题点

醍醐灌顶——我眼中的Spring Cloud

在上一篇文章中，我谈到了自己对于Spring Boot的一些想法，并且根据观察到的现象分析了很多开发者在学习和使用Spring Boot时所存在的误区以及相应的解决方案。那么...

张龙的思考

1281 4 19

e4682431aaf5

由于不是很同意老师您的说法，忍不住说下个人观点：对于搞技术的人来说，如果公司内部一直使用jsp ssh打一切，觉得提高不了自身技术，的唯一解决办法就是：跳槽。跳到一家使用分布式服务等所谓高精尖技术的公司。但是技术差面试不上咋办，哪差补哪里，挑一两个高精尖技术看原理看架构看源码，不是为了学习它们，而是为了面试。只有到了用这些技术的公司，实打实干一两年，才能真正知道这些技术能够干啥，为啥要用这些技术，然后带着好奇去真正的看原理架构和源码。很多人总爱说，环境差就自学，这句话只对了五分之一，因为根本自学不好，且效率低容易迷失方向等等。最好的学习方法就是先干，不是自己模拟干，是去公司实打实的干。只要做过rpc服务开发，就很清楚springcloud要干啥，搞那么一堆小屁组件是为了解决哪些小屁问题。马斯克关于教育有个类似的观点，教小孩螺丝刀和扳手是什么有什么作用，的方法不是拿本书看几副图片，老师站上面讲，没用，正确的姿势是，给螺丝刀和扳手等一堆工具，让小孩现场去拆一个机器。

请不要让环境限制你的成长——让你的努力落地有声

从小到大，我们都被灌输这样一个理念：环境对人的影响很大。没错，环境确实对人有着极大的影响。好的环境可以让人变得更好，差的环境可以让人变得更糟。这么多年来，身边这样的事例不胜枚...

张龙的思考

581 1 1