技术

下一个平台Agent 激发LLM涌现——提示工程 LLM微调理论及实践 大佬沉思 LLM外挂知识库 LLMOps 多模态LLM Python一些比较有意思的库 LLM部分技术源码学习 LangChain源码学习 通用分布式计算引擎Ray Python并发 go依赖注入 go collection gc的基本原理 golang性能分析及优化 数据湖 高性能计算与存储 Linux2.1.13网络源代码学习 《大数据经典论文解读》 三驾马车学习 Spark 内存管理及调优 Yarn学习 从Spark部署模式开始讲源码分析 容器狂占内存资源怎么办? 多角度理解一致性 golang io使用及优化模式 Flink学习 c++学习 学习ebpf go设计哲学 ceph学习 学习mesh kvm虚拟化 学习MQ go编译器以及defer实现 学习go 为什么要有堆栈 汇编语言 计算机组成原理 运行时和库 Prometheus client mysql 事务 mysql 事务的隔离级别 mysql 索引 坏味道 学习分布式 学习网络 学习Linux go堆内存分配 golang 系统调用与阻塞处理 Goroutine 调度过程 重新认识cpu mosn有的没的 负载均衡泛谈 单元测试的新解读 《Redis核心技术与实现》笔记 《Prometheus监控实战》笔记 Prometheus 告警学习 calico源码分析 对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go channel codereview gc分析 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes扩缩容 神经网络模型优化 直觉上理解深度学习 如何学习机器学习 TIDB源码分析 什么是云原生 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 共识算法 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全访问机制 jvm crash分析 Prometheus 学习 Kubernetes监控 容器日志采集 Kubernetes 控制器模型 容器狂占资源怎么办? Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes类型系统 源码分析体会 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 jib源码分析之细节 线程排队 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI——容器网络是如何打通的 为什么很多业务程序猿觉得数据结构和算法没用? 串一串一致性协议 当我在说PaaS时,我在说什么 《数据结构与算法之美》——数据结构笔记 PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 精简代码的利器——lombok 学习 《深入剖析kubernetes》笔记 编程语言那些事儿 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 如何分发计算 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 calico学习 AQS——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记 log4j学习 为什么netty比较难懂? 递归、回溯、动态规划 apollo client源码分析及看待面向对象设计 学习并发 docker运行java项目的常见问题 OpenTSDB 入门 spring事务小结 分布式事务 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型和jvm内存布局 java exception Linux IO学习 netty内存管理 测试环境docker化实践 netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker namespace和cgroup zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 深度学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring(八) 支持AOP 自己动手写spring(七) 类结构设计调整 分析log日志 自己动手写spring(六) 支持FactoryBean 自己动手写spring(九) 总结 自己动手写spring(五) bean的生命周期管理 自己动手写spring(四) 整合xml与注解方式 自己动手写spring(三) 支持注解方式 自己动手写spring(二) 创建一个bean工厂 自己动手写spring(一) 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM执行 git maven/ant/gradle/make使用 再看tcp kv系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 Go基础 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

架构

大模型推理服务框架 模型服务化(未完成) 大模型RHLF 大模型训练 大模型推理 从Attention到Transformer k8s设备管理 LLM工具栈 ddd从理念到代码 如何应用LLM 小鼠如何驾驭大象(LLM)? 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 容器和CPU那些事儿 kubevela源码分析 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 AutoML和AutoDL 特征平台 实时训练 分布式链路追踪 helm tensorflow原理——python层分析 如何学习tensorflow 数据并行——allreduce 数据并行——ps 机器学习中的python调用c 机器学习训练框架概述 embedding的原理及实践 tensornet源码分析 大模型训练和推理 X的生成——特征工程 tvm tensorflow原理——core层分析 模型演变 《深度学习推荐系统实战》笔记 keras 和 Estimator tensorflow分布式训练 分布式训练的一些问题 基于Volcano的弹性训练 图神经网络 pytorch弹性分布式训练 从混部到统一调度 从RNN到Attention pytorch分布式训练 CNN 《动手学深度学习》笔记 pytorch与线性回归 多活 volcano特性源码分析 推理服务 kubebuilder 学习 mpi 学习pytorch client-go学习 tensorflow学习 提高gpu 利用率 GPU与容器的结合 GPU入门 AI云平台梳理 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 学习rpc BFF openkruise学习 可观察性和监控系统 基于Kubernetes选主及应用 《许式伟的架构课》笔记 Admission Controller 与 Admission Webhook 发布平台系统设计 k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的? 《软件设计之美》笔记 mecha 架构学习 Kubernetes events学习及应用 CRI 资源调度泛谈 业务系统设计原则 grpc学习 元编程 以应用为中心 istio学习 下一代微服务Service Mesh 《实现领域驱动设计》笔记 概率论 serverless 泛谈 《架构整洁之道》笔记 处理复杂性 那些年追过的并发 服务器端编程 网络通信协议 架构大杂烩 如何学习架构 《反应式设计模式》笔记 项目的演化特点 反应式架构摸索 函数式编程的设计模式 服务化 ddd反模式——CRUD的败笔 研发效能平台 重新看面向对象设计 业务系统设计的一些体会 函数式编程 《左耳听风》笔记 业务程序猿眼中的微服务管理 DDD实践——CQRS 项目隔离——案例研究 《编程的本质》笔记 系统故障排查汇总及教训 平台支持类系统的几个点 代码腾挪的艺术 abtest 系统设计汇总 《从0开始学架构》笔记 初级权限系统设计 领域驱动理念 现有上传协议分析 移动网络下的文件上传要注意的几个问题 推送系统的几个基本问题 做配置中心要想好的几个基本问题 不同层面的异步 分层那些事儿 性能问题分析 用户认证问题 资源的分配与回收——池 消息/任务队列

标签

k8s设备管理 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 容器和CPU那些事儿 kubevela源码分析 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 helm 从混部到统一调度 volcano特性源码分析 kubebuilder 学习 client-go学习 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 openkruise学习 基于Kubernetes选主及应用 Admission Controller 与 Admission Webhook k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的? Kubernetes events学习及应用 CRI 资源调度泛谈 如何学习Kubernetes 以应用为中心 kubernetes operator kubernetes扩缩容 serverless 泛谈 什么是云原生 自定义CNI IPAM docker和k8s安全访问机制 Kubernetes监控 Kubernetes 控制器模型 Kubernetes资源调度——scheduler Kubernetes类型系统 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 Kubernetes源码分析——从kubectl开始 kubernetes yaml配置 CNI——容器网络是如何打通的 当我在说PaaS时,我在说什么 《深入剖析kubernetes》笔记 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件

2018年终小结

2018年03月31日

简介

起因,今天听了阿里口碑的架构分享,有了一些新的认识,想了很多,觉得自己还是井底之蛙

文章整体结构

  1. 阿里的分享
  2. 三年总结
  3. 年终总结

其实笔者今年纠结的这么多事儿,马克思多少年前就说了:认识世界、改造世界。

人生一直要进行的修行就是 锤炼自己的思维深度,笔者观察自己的父母,一碰上点难事就极易消极,比如“这可咋办?”

  1. 对事情的敏锐观察,难点在哪,要多长时间?
  2. 对自己的认识,哪些能做,哪些不能做?能调动哪些资源做

当一个人头脑中的疑惑积累到一定的量并且缺乏寻找答案的能力与方法时,思维就会一直处于混乱之中。外在表现就是,长期处于某一类负面情况/情绪下,且无法得到改善,进而身心疲惫。

这里的事情,一开始可能靠经验,靠经历然后对不同的事情总结汇成自己的认知体系。后面便要行成自己的认知观,以及学习观(如何摸索一个未知事物)。博学、审问、慎思、力行。

于宙:我无法忍受人类总是基于表面现象强行归纳出一堆可笑的理由. 极度崇尚第一性原理和演绎法, 痛恨类比和归纳.

三个理解

整个18年的工作经历:如何理解业务 ==> 如何理解带小团队 ==> 如何理解公司大局。

如何理解业务

主要包括:需求采集、分析、预判;用户交互(界面设计);设计方法、套路;接口设计;开发、迭代方式等。

18年做了很多前后端结合的系统,即用户操作界面,进而改变客户端、服务端的行为。因为做出来的东西偏技术领域,也主要给程序猿用,所以没有产品经理。

做用户界面,通常在程序猿来看,是很low的项目。但笔者发现,如何设计用户界面 ==> 抽象最基本的操作给用户(哪些暴露出来,哪些隐藏气起来),多一步都是浪费 ==> 思考业务,是一脉相承的。

最开始设计用户界面的时候,就是直来直去。以数据库设计出发,数据库有几个表,界面上就有几个(或者少一两个)域概念的增删改查。这样做有很多坑, 参见系统设计的一些体会

一些业务需求比较清晰,业界有比较成型的方案,自身和组内疑惑、分歧较小,在人力紧张或不紧急的情况下可以慢慢开发。反之,则需要:

  1. 设计更加谨慎,方案要经得住多个大牛的challenge
  2. 尽可能的投入主要人力,加速开发,快速试错。因为需求不明确,意味着要先做出来草稿,然后根据反馈迭代,极端情况下要推翻重写。如果人力紧缺,开发缓慢,一年再有一两个迭代,则项目会一直处于低水平“将近可用”的阶段。无法进入“需求 ==> 版本1 ==> 反馈 ==> 版本2” 的正向循环。

如何理解带小团队

尝试带好一个小团队

为何有此一问?因为你一个人出门,你背几天干粮,自己走走停停,规划路线,走错了自己走回来。你带着一帮人出去,后勤保障、行军路线、分进合击等,就很复杂。这也是为什么西汉那时候,霍去病一出去就砍成千上万的人头回来,而其他大将老是迷路和被围。

人多和一个人,有几个不同

  1. 一个人只存在时间不够,不存在人力不够的问题
  2. 一个人做的事情只影响几个人,团队做的事情 可能影响全公司
  3. 一个人只需要和几个人协作,团队需要其他团队协作
  4. 一个人总是有产出的,团队则不一定。比如按照商鞅时期的军法, 千人之将必须带领部下杀伤大于损失到一定数量才能奖赏。比如一个百夫长的“绩效”是:杀伤 - 损失 > 33 才可以晋爵一级。如果你第一次开车,那么从A开到B 就是一件很值得自豪的事情。那么之后呢,从B开到C就不那么“有价值”了。比上一次开的更快、更省油或更平稳 才有价值,也就是“增量”的部分才有价值。我们做项目也是如此,不要觉得做成一个项目就很厉害,除非那样的事情你从未做到过。

本质矛盾是什么?

  1. 你的期待是:资源到位,快速推进,成果应用,技术抱负实现,预见问题,解决问题。
  2. 实际是,每一个环节都会出问题:

    • 人力不够,机器不够,xx不够,以至于工作总是没有大的进展怎么办
    • 如果你的理念不被接受怎么办
    • 如果工作总是推不动怎么办
    • 碰到问题,不解决不行了,才开始正视问题

几点体会:

  1. 不要将自己放在与环境抵触的位置上
  2. 不要把一个事儿全抓在手里,要合作。不是说你负责这个事儿,你就所有的事儿自己干,而是把一些事儿交给最合适的人干(哪怕不是自己组),在不擅长的事情上跟随学习,在擅长的事情上主动把控。
  3. 如果你的小伙伴负责一个事情几个月,他还不足以成为这个事情的“专家”,还没有你强,还要你事事操心。要么是他不行,要么是你的失败。
  4. 很多事情不是准备好了再去做,早一点做,虽然做的不一定好,但可以先用起来
  5. 小公司应该更加看重设计,因为人力和时间有限,对方案的容错性更低。

看来的经验

  1. 团队个人应该对业务负责,而不是功能或代码
  2. 保持节奏感,这周小目标,下周小目标
  3. 亲为和团干:没有经过实践验证的事情负责人最好自己先亲为,才能深切体会,形成一定感知后优化,或者交给团队一起干。
  4. 除非是超人或者有别的重要目的,否则大多数人都只愿意做自己感兴趣的事。程序员则更是如此。
  5. 任何日程安排等带来的效率提升,都抵不过主动学习、兴趣学习
  6. 招人的一个关键原则就是新来的不能在团队中位线以下,否则团队质量会逐渐下滑至失控,后面想要再做提升调整,耗费的精力会大得多。

曾有一阵工作的抱怨

  1. 我们的大部分项目是对需求的被动反应,稳定和可靠虽然是目标,但实际上从来没有认真对待过(因为这意味着专门的人员和精力的分配)。因为你不能一边产品的需求在加码,一边说我们今年的目标主要是稳定
  2. 管理不够精细化,很多时候,既不知道这个项目的复杂性是多少、目标也定义的不够清楚、人员的能力不够清楚、他的精力也不确定,然后就让他去做了。以至于实质上大量的关键决策下沉了。

如何理解大局

今年面临的一个很大问题就是缺人,所以最开始 领导说我事情做得还不够好的时候,我其实挺委屈。但从另外一个角度看,若是缺人的现状短期内无法改善(有时候招个不合适的更难受) 我就一直抱怨着么?反过来说,现状要求我

  1. 更多的技术分享,提高单兵作战能力
  2. 更好地代码质量,人员可以快速适应和调配
  3. 更好地系统设计,提高容错性,减少后期变动的可能性
  4. 更多的基础服务,提高复用性

永远不放弃寻找突破口。领导不认可、同意、支持。先不要忙着沮丧

  1. 是不是自己的判断、意见错了
  2. 是不是领导不熟悉整个过程导致的错误判断
  3. 是不是时机不合适?
  4. 是不是已有的工作还未做到位
  5. 是不是在你的方案中夹杂了过多自己的想法和兴趣

在公司的工作有很多事,一些事儿是你感兴趣的,一些事儿是你不感兴趣的,两者的比例是你能否开心的关键。勇于向leader 表达你的兴趣,拒绝或减少不喜欢的工作。

行业大局

从今年,应该可以感受到:现在已经不是做个app就算创业的时代了。专业名词就是消费互联网(获取、分享信息)逐渐玩剩下了,新的一些东西比如产业互联网、人工智能等,还有传统互联网的沉淀,技术经过扩散和培育,开始通用化和平台化。比如A 公司的高并发和B公司的高并发解决方案可能并没有很大区别,这些解决方案开始产品化的输出。一些基本的能力开始沉淀,比如云计算等。

这意味着: 编程技能虽然依然很宝贵,但随着框架 的沉淀和普及,对人的要求在降低。就好比,牛逼的机床师傅依然牛逼, 但很多部件已经可以3d打印了。

互联网有一个趋势,就是大公司大平台的技术已经过剩,在自身业务已经逐渐趋向天花板的情况下,技术部也开始思考作为一个业务单元或者说事业部向外拓展业务的问题了。而面向企业客户输出各种技术服务,帮助传统非互联网企业向 + 互联网转型,显然是一片很大的蓝海。

李列为:右侧是社会碎片劳动力,左侧是碎片资源,而各大公司都在向上走,争做“大脑”。公元前 300 年,孟子说过:劳心者治人,劳力者治于人。

单体资源的使用,都有负载“峰谷”,而这种情况,也造成了资源的浪费,共享,可以实现“削峰填谷”,资源使用得以平滑。这种现象推而广之,就是无数商家在没有平台之前较高的准入门槛(店铺、资金、运输工具等),而现在淘宝开个店铺就可以卖货。

资本流、信息流、物流有了大脑的之后,一个加速;一个降低成本

技术大局

从技术演进感受技术大势

解读2018:我们处在一个什么样的技术浪潮当中?

近十年来互联网技术发生了非常大的变化:

  1. 在软件架构领域,经历了从单体应用到 SOA 再到微服务;
  2. 在云计算领域,经历了从虚拟机到容器;
  3. 在数据库领域,从关系数据库到 NoSQL 再到 NewSQL;
  4. 在大数据领域,从批处理到流处理;
  5. 在运维领域,从手工运维到 DevOps、AIOps;
  6. 在前端领域,从 jQuery 到 React 等三大框架;

除此之外,还有一些新兴的领域如 AI、区块链,从不受重视到成为显学,开启了一波又一波的风口。单个去看这些领域的发展,会觉得纷繁杂乱没有头绪,但如果从整体上去看,会发现它们相互之间有联系,它们的发展源于一种共同的推动力,遵循着相似的逻辑。如果要对这个推动力、对今天这个技术浪潮起一个名字,在当前阶段我觉得可以用“云原生”,但这个短语被过度使用在各种营销语境中,它的定义会发生偏离,所以后文我不会用这个短语,而是用真正的云计算这句话。

我们当前技术浪潮的真实含义,就是我们正在走向真正的云计算时代,其它领域的发展皆由此而来,如果要更具体一点,就是:

  1. 云计算的技术逐渐发展成为它本来该有的模样;
  2. 以及与这样的云所匹配的软件架构;
  3. 以及与这样的架构所匹配的开发流程与方法论。

从互联网到移动互联网,是一个不断扩张的过程,不但终端节点大量增加,而且每时每刻都在线,如果将这个逻辑延伸一下就是物联网了,终端从智能手机变成任何可联网的设备。

信息技术的革命将把受制于键盘和显示器的计算机解放出来,使之成为我们能够与之交谈,与之一道旅行,能够抚摸甚至能够穿戴的对象。这些发展将变革我们的学习方式、工作方式、娱乐方式—一句话,我们的生活方式。——尼葛洛庞帝《数字化生存》

如果将上面的各个领域的重要技术变革提炼一下,会发现其中的一些有共同点:

  1. 虚拟化:将硬件资源虚拟为软件资源,然后进行统一调度和管理。隔离:从虚拟机到容器,再到虚拟机与容器融合,隔离的技术定义了云的形态。
  2. 解耦:无论是后端的微服务、前端的前后端分离、组件化等等,都是将关注点分离,解耦合的过程。编排:大量不同的服务、任务,让他们组成一个整体,相互间能良好的协作。
  3. 智能化:让服务个性化,或者让自动化替代以前需要人工完成的事情。
  4. 实时化:计算和处理在极短时间内完成,从而实时的给予反馈。

自己的体会:机器学习是什么?分类(Classification)和回归(Regression)。基础设施(虚拟化、隔离、编排)和软件架构(微服务、编排),都在打散和组合,组合是粘合打散的节点,打散是为了更好、更快、更独立的演化。

如果要预测软件的发展,我们不能不去看硬件可能带来的提升(注意这种思维方式),这里我们从软件运行需要的三大资源入手:

  1. 计算:AI 对于计算的特殊需求,催生了相关芯片的研发。而更多非通用性芯片将推动物联网和边缘计算的发展。而在远处忽隐忽现的量子计算,一旦能普及,也必将产生颠覆。
  2. 存储:Nano Flash 类非易失性存储还有提升的空间,在云和端的利用也没有普及。如果非易失性存储能在内存领域有所突破,对于软件架构必将带来另一次颠覆。
  3. 网络:网络方面,WiFi 技术即将进入第六代,带来拥挤场合的大幅性能提升;蓝牙进入第五代,连接距离将提升至 300 米;更重要的则是 5G,相较于 4G 数百倍的数据传输速度和低至几毫秒的延时,让很多应用都有了更大的想象空间。

解读 你真正理解什么是Cloud Native吗?持续交付、DevOps和微服务分别描述了cloud-native应用的为什么、怎么做和是什么。这些竞争优势迅速成为玩转软件游戏的赌注。

其它

极客时间《技术领导力300讲》:举个例子,IDC 数据中心之上出现了云,云之上又出现了云平台,之后就是各种应用。这就像一个金字塔,底层地基不断往上搭建,底下就会被各种厂商进行商品化、产品化。在过去十几年,对于创业者来说很多底层工具可能就已经是非常大的技术挑战了,技术人需要自己去攻克。但当这些工具越来越多的被商品化、产品化时,这就要求我们的技术领导者去做更上层的技术。

从程序员到CTO都应该了解的一些技术趋势一如既往的根本问题,是如何在隔离和耦合之间取得平衡:我们隔离组件,使其在技术角度便于管理。但是我们也需要协调组件,使其有助于解决业务问题。这就产生了某种形式的耦合。(到处都在说隔离/拆分和耦合)

容器化、响应式前端和机器学习都是很好的例子。这时技术处在爆发阶段。然而,只有在明确如何与长期以来的工程实践(持续交付、测试、协作等)相结合之后,新技术才能真正的发挥功效,并进入沉淀阶段,为下一次爆发性扩张打下坚实的基础。

请千万谨记,微服务是通过开发复杂度来换取运维复杂度,并需要自动化测试、持续交付和 DevOps 文化提供坚实的支撑。可观测性是运转分布式系统与微服务架构必不可少的一部分。我们依赖不同的系统输出来推断分布式组件的内部状态,比如分布式追踪、日志聚合、系统指标等,进而诊断问题所在,并找到根本原因。

学习工作习惯

实践才是学东西最快的,不追求某项特定的技术,而是追求去做 有足够复杂度的项目。项目可以做的比较复杂,但你能不能设计的比较简单。

无动机不学习。学一个东西,一定要有一个还算强烈的动机。学一阵儿,发现没兴趣了,也不要沮丧,或者因为你累了,或者外界需求还比较弱,那就等一等,攒一攒需求,等好了再学。

允许自己漫无目的的学,哪怕看看自己的博客,改改其中的错漏,一天下来也感觉很充实。用收获感对抗焦虑。

纲举目张,今年买了一些付费节目,一个付费节目本身学到东西,另一个是作者在论述文章时,产生很多名词,提到过好多书(我买了几本)。除了字面上内容的提升,还有其隐含的知识体系的提升。

研究源码,类图就好比 一个地图的 各个山头,虽然不是地图的全部,但撑起了骨架。 一个要提高各种感知手段。报警、性能图表等,查看服务器连接状态、heap dump、thread dump等

读书在当今的时代真的是一项能力,一本书看完,作者想表达的观点到底是什么,如何与你的生活与实际进行结合,书中的知识怎么和你的存量知识进行连接,这是一个需要长期锻炼的能力

打破自己的舒适区

  1. 你能不能一天看完 一本书(纯算法等逻辑含量很高的除外)
  2. 你能不能 一天设计一个系统,其完备性经得住小伙伴质疑
  3. 碰到一个新的开源项目,你能不能一天取得一个深刻的认识。
  4. 前三点都需要你有一套方法论,基于以上,碰到一个事情,你敢不敢放心的交给别人做(设计、分析、实现等),你解决问题的办法只有一个(也就是自己干)么

朝人性做逆功,消除四心:脆弱、自满、自怜、虚荣

今年开始有一种很明显的感觉:时不我待。开始非常主动地加班、周六日全部用来在公司/咖啡馆看书。一个重要原因是之前在各个技术领域的涉足开始收敛(原来一直担心泛而不精),逐渐一两天可以看完一本技术密度一般的书、复杂度中等的框架,博客中开始大量的出现“参见之前写的xx”。这给我带来了很大的获得感,如果说以前还在“看几页书”与“出去玩、跟妹子聊天”之间纠结的话,同样的时间,跟妹子有的没的的聊天与吃掉一本书相比毫无竞争力。这或许就是金庸小说说的,内力高深之后,学什么都特别快(这话说的有点托大了)。

如何看待大牛的经验文

知识的广度和深度

程序猿常见的思维误区

生活

时间管理

管理时间,不单纯要管理时间,还要管理你的同事,甚至上级。当你被动的做一件事儿,情绪很容易焦躁。时间管理也是优先级管理。

朋友,你的时间够用吗?

我们所能做的,是以投资的眼光来看待时间的分配问题。哪些跟长远目标(收益)有关,哪些跟短期目标(收益)有关,这是我们需要考虑的问题。短期来看,每天完成一个小目标,重要的事情要先做;长远来看,认清方向,在一段时间内有所为有所不为。在对时间的投资上,做个冷静的投资者。专注目标,疏解内心.

其它

无论什么东西,如果想有个持久的进步,或者保持兴趣 最好就是 利用这个东西获得收益,无论是物质上、情绪上(比如虚荣心)等。

在博客中更多的脑图,脑图是比文字更好的表达知识的方式,因为脑图是有层次的(内/外环)。而脑子大多数时候一堆浆糊的原因就是 各种层次的细节 一下子涌入。

坚忍、静定、勇敢、目标始终如一