寒冬的思考
俗话说"金三银四"，四月份快过完了，不知道大家面试的怎么样了。
2018年冬天是寒冷的。其实18年的低温持续时间不算很长，我也没有披上军大衣。但是突如其来的互联网寒冬影响了不少人，互联网寒冬当然主要受影响的就是程序员了。
回顾过往，2017年是互联网高速发展的一年，共享经济仅仅一个概念就成就了多少家公司，各种共享单车满天飞，然而到了2018年下旬，好像所有的情况都发生了变化，你会发现所有互联网从业人员都在大喊，互联网寒冬来了，摩拜卖身于美团，美团又大裁员引发职言的刷屏，网易、滴滴、爱奇艺、京东这些各自领域的强者企业也都发生着裁员。除此之外，相对小些的公司比如知乎、锤子科技、斗鱼等企业也分别进行了不同程度的裁员，更别说哪些更小的互联网公司，各种倒闭，破产，不付工资。
伴随着这些企业裁员的发生，这些被裁的员工，可以说大部分是程序员，他们会陆陆续续全部回流到招聘市场。但是又有多少企业能接收他们呢？你要知道市场上不只这些被裁的还有那些主动离职“换更大平台”的。千军万马过河，寒冬里企业为什么选择你，在你和他之间拼的就是各自的实力了，这时有的人就自信满满而有些人则心慌慌了。
同是三、五年的工作经验，但是工资和职位级别却相差甚远，入职新公司发现比自己年龄小的做了自己的领导，这种感觉真是有苦难言啊。
这种情况，让年后准备离职的人也犹豫了不少，毕竟稳定的职业还能解决生计，跳槽不好跳到坑里可就不美好了，也让很多人持观望态度，因为不知道外面现在是什么行情，所以裸辞的就坚决不建议了，除非你足够自信。
普遍的现象
对于互联网寒冬，有能力的人自然无所畏惧，21世纪嘛，毕竟是以人才为核心发展力。程序员的工资如果想要在短期一次涨很大幅度，通常只能通过跳槽来实现了，但是还是有很多人不敢轻易尝试，跳槽虽然能够涨高幅度的工资，但是也是和自身能力挂钩的，而能力来自于以往工作中获取积累而得的。
程序员行业中，存在一个普遍现象，那就是：工资并不是和工作年限密切相关的。其他行业你也许工作年限越久、工作资历越高、经验越丰富，然后职位和工资就越高。但是程序员行业不同，在程序员职业中，不说同年限的工作薪资差别大了，可能一个5年工作年限的也许工资还没有工作3年的高，在一个组中也许3年的领导着5年的人做事。
想想，为什么会出现这种现象呢？为什么你就是那个悲剧的人，而别人就是那种遥遥直上的人？很失落但是也要想原因。其实和自己在迎接瓶颈期和处理瓶颈的问题上的态度息息相关了。
瓶颈，生活中一种下宽上窄的瓶子颈部，瓶内物要倒出瓶外，一般在瓶颈处要么阻塞要么会限流。而“瓶颈”在事业上，一般用来形容事业发展中遇到的停滞不前的状态，这个阶段就像瓶子的颈部一样是一个关口，如果没有找到正确的方向有可能一直被困在瓶颈处。
程序员的瓶颈期，因人而异，大部分人可能在工作5年左右的时候迎来了自己的技术瓶颈，有的人是起点高也有可能在3年左右迎来自己的瓶颈期。在遇到瓶颈期时，有的是继续深度挖掘技术但收效甚微，而有的是无奈则试着转型做管理或产品，转行的应该也有但很少。
瓶颈期的表现为：新技术学不动，原技术我都了解且熟练使用，但是都一知半解。工作中游刃有余但是一遇面试就坑坑巴巴。
瓶颈的原由
为什么会有瓶颈呢？常说 IT 行业是一个时常保持学习的行业，程序员需要有敏锐的新技术嗅觉。都说“30以后年纪大了，学不动了。”如果只是编码的话需要逻辑清晰脑力活跃。其实年龄这个理由只是客观因素，技术是不断更新的没错，30岁脑记忆力跟不上年轻的时候也对。但是这只是客观的外界因素。
程序员都应该以30岁为一个标点。30岁的时候学技术不可能还像年轻的时候那样学习方法。看视频，需要老师教，同学指点。程序员干到30岁应该都有一个自己的技术池了，学习新技术会是一个举一反三的态度。
宋代禅宗大师青原行思，提出了人生的三重境界：参禅之初，看山是山，看水是水；禅有悟时，看山不是山，看水不是水；禅中彻悟，看山仍是山，看水仍是水。那么我们应该怎样理解这三种境界的意思呢？
程序员学习技术应该也是这样的三个阶段的过程，30岁也许你没达到彻悟但是肯定要达到有悟的境界了。
如果你焦虑，其实归纳起来主要是：在不该安逸的年纪享受着舒适区，生于忧患，死于安乐。我这不是提倡996，废寝忘食。而是提醒不要混日子，因为混日子，最终会混了自己。在工作业余时间总结技术，而不是看直播，农药和撸啊撸。
别人比你年轻技术比你好当你领导，也许并不是他很聪明，而是他在你看直播和农药的时候多写了一个 Hello World。
解决之道
阅读经典源码，理解思想
武学讲究师从名门，大师指导进步自然快。经典的技术框架都是大师的技术手艺展现，还有什么比这个更有指导意义吗?
阅读源码有助于我们学习经典的技术思想和代码编写套路，在我们以后项目中造轮子有思想指导价值。
阅读源码有助于我们更了解技术的实现和脉络，做到知己知彼，在遇到线上问题的时候解决问题能做到精确定位，比别人技高一筹。
知其然，知其所以然
技术是一个累积的过程，工作多年的你也许已经换了几份工作，每家的技术使用肯定都不一样，排除SSM框架，肯定新家都有上一家公司没用到的技术。
学习新技术，一般都是自己倒腾写个Hello world，但是这样是只能是停留在会用的阶段，只是“知其然”，而我们如果想要走的远必须"知其所以然"。
我认为公司项目中如果使用了一个新技术的时候，趁这个时候有实际项目可以验证，我们应该将该技术熟练掌握，不仅仅包括它的使用API，还要包括原理，源码甚至可能遇到的生产问题的解决方法。
我们尽量避免不必要的重复学习，因为要学的技术实在太多，在接触到他的时候我们就将它融化在自己的技术池中，在以后再见面的时候我们就可以拿出来使用了，还可以查漏补缺。
例如新手接触到spring框架，我们不要只停留在知道如何配置它，xmL方式配置，注解方式配置等等，我们还要理解他的IOC，以及如何实现的IOC，还有更深点的spring的bean生命周期，理解了bean的声明周期之后我们就可以在项目中使用各种生命周期中的注解和接口来实现自己业务要求，例如@PostConstruct 和 @PreDestroy ，还有ApplicationContextAware接口的作用等等。
未雨绸缪
我们永远不要停留在已掌握的技术中，而应该主动拥抱自己未知的技术。面试的时候也许面试官会找你掌握的技术问，但是你找工作不可能下家用的都是你现在会的技术，未雨绸缪，学习现在市场上一些新出的技术，对你以后职业发展可以提供更宽的道路。
也许你们公司没有使用微服务的架构，但是你自己可以先研究SpringCloud 和 Docker。也许你项目没有使用 Elasticsearch 但是你可以在本地安装并使用。机会总是留给有准备的人。
勇于挑战新机会
人都是逼出来的，不到危机时刻永远不知道你自己有多大的潜力。不是刚毕业就能当架构师，但是按照上面你都做好了积累，一切准备就绪，待时机成熟的时候要勇于转变自己的职业角色。任何开发的程序员我认为在工作5年左右的时候都可以转变成架构师的角色了，因为只要你认真对待了前面那几年，这时候是可以胜任的，而这时候也差不多正是30岁左右的时候。
架构师该掌握的微服务和分布式（Java）
微服务架构
现在深圳地区招Java岗，首要要求就是会微服务。
微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务的元年；
越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，可以说这样更近一步推动了微服务的发展和创新。
微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的
类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。
概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。
本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。这些知识点都是我从业多年总结出来的的经验，都是当前最主流的技术。
下图是我总结的微服务的技术要点：
分布式架构体系
分布式怎么来的。传统的电信、银行业，当业务量大了之后，普通服务器CPU/IO/网络到了100%，请求太慢怎么办？最直接的做法，升级硬件，反正也不缺钱，IBM小型机，大型机，采购了堆硬件。
但是互联网不能这么干，互联网没有那么财大气粗，还有很多初创，能不能赚钱还不知道。所以就有了软件方面的解决方案：分布式系统，简单说，就是一台服务器不行，我用两台、10台、100台...这就要软件系统需要支持。
那么多台机器，我如何让他们协同工作，这就需要一个调度中心（或注册中心）；肯定涉及到机器间通信，那么需要一个高效的RPC框架；一个请求过来了，如何分发，需要一个请求分发系统（负载均衡）；然后还要考虑每个角色都不能成为性能瓶颈；还有要能方便的进行横向扩展，还有考虑单节点故障。
需要分布式系统，并发量肯定不低，
那么有了上面的还是不够的，还需要考虑cache、mq、job、db等方面的问题。cache，现在第三方缓存也比较成熟，redis/memcache等；mq，rabbitmq,kafka等等也不错；job，现在第三方任务框架有elasticjob和tbschedule，或者你用quartz也支持分布式环境下的任务，不过quartz就没有运维工具了。DB，数据库最好在项目前期就考虑好业务拆分，系统拆分后DB对应的垂直拆分，后期可做读写分离，一主多从，甚至多主多从，业界也有了相应的解决方案。
总结一下，首先要了解分布式原理，然后对应着每个功能区找业界内成熟的产品来实时。互联网行业，基本都有开源的产品供你选择。
下图是我总结的分布式的技术攻克点：