关于软件架构师讨论

一、

刚当程序员时，我是属于那种勤勤恳恳类型的员工，工作态度用认真来形容不为过，每天我几乎是团队里最早到公司，又最晚下班的一个。而组员张工一般情况下都是准时上下班的，即使项目进度比较紧急，他也很少加班，除非是有特殊情况，他才加班。

要是按勤奋程度和工作时间长短来衡量，我想我比张工积极多了。按理说，我这么积极，工作量应该比张工多才对，其实不然，领导安排给我的工作任务和张工的任务相比，我比他还要少。

张工之前是做java服务端的，后来自学了Android移动开发，再后来又自学了iOS移动开发，那时他就是一位多能手，项目安排他做什么他就能做什么。

从张工提交的代码看，他的代码不仅规范而且很优雅，大的不说，就他能对一些基本控件进行封装处理，还做了拓展，方便给其他开发人员调用，就已经很让我敬佩不已了。

而我所谓的工作时间长，其实大多时间是在重复地造轮子，一个相同的功能重复做，不仅没有做封装处理，导致冗余代码还多，有时候刚好碰到需求改动，我就把自己累得够呛，现在想想，真的活该啊。

二、

类似这样的情况不知你身边有没有：

读书的时候，有的同学上课时眼睛睁得特别大，还做笔记，一节课下来，笔记本里密密麻麻的，课后做的练习题也不少，可成绩却差强人意。而有些同学表面看似不怎么努力，学习成绩却保持很好。
工作时，有些人总是“加班”，看起来很敬业，而他们上班时间却一会儿逛淘宝，一会儿刷微博，看头条，该上班时间完成的他们留在了下班时间做。

有时候我会有一种错觉，觉得自己明明很努力了，连碎片化时间都拿来学习，可进步却不大。

甚至本该闲着的时间，为了不让自己闲着，找了一大堆事情来让自己忙碌起来，貌似挺充实的。一段时间后，发现没有取得什么成绩，越努力越失败，于是陷入迷茫。“你看看，我都这么努力了，怎么还是老样子。” 渐渐开始怀疑自己，继而消沉，甚至萎靡不振。

其实闲着并不可怕，闲着也是一种享受，能够保持闲着也是一种能力，可怕的是，我们觉得是在虚度时光，盲目地给安排了一些无关紧要的事情，反而为自己努力而感动的不要不要的。

请不要让自己只是看起来很努力，因为结果不会陪你演戏.要让别人羡慕，太容易了，适当装一下就可以了，但要让自己羡慕自己，就有点难了。

职场上，懂得不断的督促自己，适当地给自己施加危机感。怠慢心理，优哉游哉的心境适合逛商场，本来一个小时就能做完的工作，要是没有紧迫感，优哉游哉地，怕是下班了都墨迹不完，久而久之，养成了一种习惯，这并不明智。

真正的努力，不是比谁花的时间多，看上去谁更加努力，而是能否找到合适自己的方法，然后多思考，多总结，摸索一套适合自己的学习方法。

忙碌的时候也要注意劳逸结合，一味的埋头工作如同老牛拉犁一样，人的体能是有限的，大脑也是需要休息，超负荷的工作只能降低工作效率，很难产生事半功倍的结果。适当的放松下，喝杯水，让身心放松下来，或许有意外的收获。

不知你有没有发现，接触的人多了，层面越高，成功的人士大多都懂得彼此相互支持，抱团取暖，因为我好，你也好，你好，我也好，大家好才是真的好。而往往事业不怎么如意的人，越是喜欢诋毁嫉妒，拆台，因为我不好，你也甭想好。

所以和有格局有想法的人一起共事也很重要。

学习是对自己最好的投资，而机会属于有准备的人，这是一个看脸的时代，但最终拼的是实力。人和人之间的差距不在于智商，而在于如何利用业余时间，所以没有等出来的辉煌，只有干出来的精彩。其实只要你想学习，什么时候开始都不晚，不要担心这担心那，你只需努力，剩下的交给时间，而你之所以还没有变强，只因你还不够努力，要记得付出不亚于任何人的努力。

无聊不学习，是年轻人的绝症，可是别忘喽，没有一种青春不辛苦，我们绝不能贱卖我们的青春，每天混饭吃，所以你必须逼自己一把，否则你永远不知道自己有多么的优秀，要永远坚信，财富就在你的脑子里，只要你决心成功，失败永远都不会把你打倒，你的未来不需要别人保证，要把生命浪费在美好的事物上，杀出一条血路。也请你不要在骗自己了，你不是没时间，你也不是很牛掰，你更不是很累，只有通过今天不起眼的学习，才会成就你明天的了不起，这样才能把这辈子活的热气腾腾，要记住屌丝恒久远，逆袭永流传不要在给自己不学习找借口了，否则你永远都是一个屌丝。

三、

1、我没有口才——错：没有人天生就很会说话，台上的演讲大师也不是一下子就能出口成章，那是他们背后演练了无数次的结果！你骂人的时候很擅长、抱怨的时候也很擅长、但这种口才是没有价值的口才，看别人争论的时候、自己满嘴评头论足、却不知反省自己，倘若你付出努力练习，你今天是否还说自己没口才？

2、我没有钱——错：不是没有钱，而是没有赚钱的脑袋。工作几年了没有钱么？有、但是花掉了。花在没有投资回报的事情上面。花在吃喝玩乐上、或存放贬值了，没有实现价值最大化、所以钱就这样入不敷出。每月当月光族、周而复始、没有远虑、当一天和尚敲一天钟，得过且过。

3、我没有能力——错：不给自己机会去锻炼，又有谁一出生就有能力？一毕业就是社会精英？一创业就马上成功？当别人很努力的学习、很努力的积累、努力找方法，而你每天就只做了很少一点就觉得乏味。学了一些就觉得没意思、看了几页书就不想看、跟自己也跟别人说没兴趣学。然后大半辈子过去一事无成，整天抱怨上天不给机会。能力是努力修来的、不努力想有能力，天才都会成蠢材。但努力，再笨的人也能成精英。

4、我没有时间——错：时间很多、但浪费的也很多！别人很充实、你在看电视，别人在努力学习时、你在玩游戏消遣虚度。总之时间就是觉得很多余、你过得越来越无聊。别人赚钱了羡慕别人、但不去学别人好好把握时间创造价值，整天不学无术。

5、我没有心情——错：心情好的时候去游玩、心情不好的时候在家喝闷酒，心情好的时候去逛街、心情不好的时候玩游戏，心情好的时候去享受、心情不好的时候就睡大觉。好坏心情都一样，反正就是不做正事。

6、我没有兴趣——错：兴趣是什么？吃喝玩乐谁都有兴趣，没有成就哪来的尽兴！没钱拿什么享受生活！你的兴趣是什么？是出去旅游回来月光族、出去K歌回头钱包空空、出去大量购物回来惨兮兮……打工有没有兴趣？挤公交车有没有兴趣？上班签到下班打卡有没有兴趣？家里急需要一大笔钱拿不出来有没有兴趣？借了钱没钱还有没有兴趣？卖老鼠药的人对老鼠药有兴趣……？

7、我考虑考虑——错：考虑做吧有可能就成了、不做吧好不甘心！一想整天上班也没有个头、还是明天开始做吧！又一想还是算了、这钱挣的也不容易！不不、就是打工挣钱也不容易，决定了不能放弃机会！哎呀、天都黑了，明天再说吧！然后第二天又因为以上几点、因为左思右想、继续循环、最终不能决定。犹犹豫豫、耽误了很多时间、还是一无所获。

有句话是：“可怜之人必有可恨之处！”你一生中不是没有机遇，而是没有争取与把握！借口太多，理由太多……！争取之人必竭力争取、一分钱都没有也千方百计想办法争取。

java开发人员可以看过来。

对于参加工作1年到2年的同学。这部分时间段的同学，已经对Java有了一个更加深入的了解。

对于参加工作2年到3年的同学有的同学在这个时候觉得自己已经很牛逼了，于是忍不住开始慢慢松懈。

参加工作3年到4年的同学这个阶段的同学，提升已经是很难了，而且这个阶段的学习往往会比较多样化。

参加工作4年到5年的同学经过前面一年的历练，相信你在自己所钻研的领域已经有了自己一定的见解，这个时候，技术上你应该已经遇到瓶颈了。

为大家分享自己总结的架构师学习路线图，大家可以拿来做一个参考：

一、分布式架构体系

分布式怎么来的。传统的电信、银行业，当业务量大了之后，普通服务器CPU/IO/网络到了100%，请求太慢怎么办？最直接的做法，升级硬件，反正也不缺钱，IBM小型机，大型机，采购了堆硬件。

但是互联网不能这么干，互联网没有那么财大气粗，还有很多初创，能不能赚钱还不知道。所以就有了软件方面的解决方案：分布式系统，简单说，就是一台服务器不行，我用两台、10台、100台...这就要软件系统需要支持。

那么多台机器，我如何让他们协同工作，这就需要一个调度中心（或注册中心）；肯定涉及到机器间通信，那么需要一个高效的RPC框架；一个请求过来了，如何分发，需要一个请求分发系统（负载均衡）；然后还要考虑每个角色都不能成为性能瓶颈；还有要能方便的进行横向扩展，还有考虑单节点故障。

需要分布式系统，并发量肯定不低，

那么有了上面的还是不够的，还需要考虑cache、mq、job、db等方面的问题。cache，现在第三方缓存也比较成熟，redis/memcache等；mq，rabbitmq,kafka等等也不错；job，现在第三方任务框架有elasticjob和tbschedule，或者你用quartz也支持分布式环境下的任务，不过quartz就没有运维工具了。DB，数据库最好在项目前期就考虑好业务拆分，系统拆分后DB对应的垂直拆分，后期可做读写分离，一主多从，甚至多主多从，业界也有了相应的解决方案。

总结一下，首先要了解分布式原理，然后对应着每个功能区找业界内成熟的产品来实时。互联网行业，基本都有开源的产品供你选择。

下图是我总结的分布式的技术攻克点：

二、微服务架构

微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务的元年；

越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，可以说这样更近一步推动了微服务的发展和创新。

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的

类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。

本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

这些知识点都是我从业多年总结出来的的经验，都是当前最主流的技术。想学习这些技术的朋友可以加群。群里会分享这些技术知识点供大家学习免费下载（想要加群的话私我哦）

下图是我总结的微服务的技术要点：

三、阅读源码、分析源码

程序员每天都和代码打交道。经过数年的基础教育和职业培训，大部分程序员都会「写」代码，或者至少会抄代码和改代码。但是，会读代码的并不在多数，会读代码又真正读懂一些大项目的源码的，少之又少。这种怪状，真要追究起来，怪不得程序员这个群体本身 —— 它是两个原因造成的。

我们所有的教育和培训都在强调怎么写代码，并没有教大家如何读代码

大多数工作场景都是一个萝卜一个坑，我们只需要了解一个系统的局部便能开展工作，读不相干的代码，似乎没用

我常常把写代码和写作进行类比 —— 二者有很多相通之处;但从培养写代码和写作的过程来看，二者又有很多不同。我们的写作能力，是建立在大量基础阅读的基础上的，是除了学习语法和文法知识外，从小学开始，经年累月，通过阅读各种不同层次的名家的作品，再加上各种各样的写作训练，累积出来的;而我们的写代码的能力，在了解和掌握了语法/文法之后(学习和抄写 example 代码也算语法/文法学习的一部分)，跳过了大量阅读名家作品的过程，直接 biu 地一下就自动养成了：学会基础的语法和试验了若干 example 后，我们就火箭般蹿到了自己写代码打怪赞经验的阶段。这样略过大量阅读代码的阶段有三个害处：

写代码的基础是不牢靠的，打怪升级的过程也是最慢的。道理很简单 —— 前辈们踩过的坑，总结的经验教训，你都不得不亲自用最慢的法子一点点试着踩一遍。

很容易养成 stackoverflow driven 的写代码习惯 —— 遇到不知如何写的代码，从网上找现成的答案，找个高票的复制粘贴改吧改吧，凑活着完成功能再说。写代码的过程中遇到问题，开启调试模式，要么设置无数断点一步步跟踪，要么到处打印信息试图为满是窟窿的代码打上补丁，导致整个写代码的过程是一部调代码的血泪史。(见我的文章：你要避免的软件开发模式)

你周围最强的那个工程师的开发水平的上限就是你的上限。

下图是作为程序员最需要了解的源码体系：

四、工具的使用

工欲善其事必先利其器，工具对Java程序员的重要性不言而喻现在有很多库、实用工具和程序任Java开发人员选择。下图列出的工具都是程序员必不可少的工具

五、性能优化

性能优化，简而言之，就是在不影响系统运行正确性的前提下，使之运行地更快，完成特定功能所需的时间更短。性能问题永远是永恒的主题之一，而优化则更需要技巧。

发布于 2019-06-26

程序员的三个阶段

第一阶段—三年

我认为三年对于程序员来说是第一个门槛，这个阶段将会淘汰掉一批不适合写代码的人。这一阶段，我们走出校园，迈入社会，成为一名程序员，正式从书本上的内容迈向真正的企业级开发。我们知道如何团队协作、如何使用项目管理工具、项目版本如何控制、我们写的代码如何测试如何在线上运行等等，积累了一定的开发经验，也对代码有了一定深入的认识，是一个比较纯粹的Coder的阶段。

第二阶段—五年

五年又是区分程序员的第二个门槛。有些人在三年里，除了完成工作，在空余时间基本不会研究别的东西，热衷于研究各种技术实现细节、看了N多好书、写一些博客、在Github上分享技术，这些人在五年后必然具备在技术上独当一面的能力并且清楚自己未来的发展方向，从一个Coder逐步走向系统分析师或是架构师，成为项目组中不可或缺的人物。

第三阶段—十年

十年又是另一个门槛了，转行或是继续做一名程序员就在这个节点上。如果在前几年就抱定不转行的思路并且为之努力的话，那么在十年的这个节点上，有些人必然成长为一名对行业有着深入认识、对技术有着深入认识、能从零开始对一个产品进行分析的程序员，这样的人在公司基本担任的都是CTO、技术专家、首席架构师等最关键的职位，这对于自己绝对是一件荣耀的事，当然老板在经济上也绝不会亏待你。

我认为随着工作年限的增长、对生活对生命认识的深入，应当不断学习思考

关于专业技能

Java程序员应该具备的技能，这可能是Java程序员们比较关心的内容。

我这里要说明一下，以下列举的内容不是都要会的东西。但是如果你掌握得越多，最终能得到的评价、拿到的薪水势必也越高！

一.源码分析专题