技术

mosn有的没的 负载均衡泛谈 《Mysql实战45讲》笔记 单元测试的新解读 《Redis核心技术与实现》笔记 《Prometheus监控实战》笔记 Prometheus 告警学习 calico源码分析 对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go细节 codereview mat使用 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自动扩容缩容 神经网络模型优化 直觉上理解机器学习 knative入门 如何学习机器学习 神经网络系列笔记 TIDB源码分析 《阿里巴巴云原生实践15讲》笔记 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监控 容器狂占cpu怎么办? Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes objects 源码分析体会 《数据结构与算法之美》——算法新解 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学习 AQS2——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 硬件对软件设计的影响 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记2 《mysql技术内幕》笔记1 log4j学习 为什么netty比较难懂? 回溯法 apollo client源码分析及看待面向对象设计 学习并发 docker运行java项目的常见问题 Scala的一些梗 OpenTSDB 入门 spring事务小结 事务一致性 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型 java exception Linux IO学习 netty内存管理 测试环境docker化实践 netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker中涉及到的一些linux知识 hystrix学习 Linux网络源代码学习——整体介绍 zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 Redis概述 机器学习泛谈 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 spring rmi和thrift maven/ant/gradle使用 再看tcp 缓存系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 VPN(Virtual Private Network) Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 Go学习 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

架构

Scheduler如何给Node打分 Scheduler扩展 controller 组件介绍 openkruise cloneset学习 kubernetes crd 及kubebuilder学习 pv与pvc实现 csi学习 client-go学习 kubelet 组件分析 调度实践 Pod是如何被创建出来的? 《软件设计之美》笔记 mecha 架构学习 Kubernetes events学习及应用 CRI 《推荐系统36式》笔记 资源调度泛谈 系统设计原则 grpc学习 元编程 以应用为中心 istio学习 下一代微服务Service Mesh 《实现领域驱动设计》笔记 serverless 泛谈 《架构整洁之道》笔记 处理复杂性 那些年追过的并发 服务器端编程 网络通信协议 《聊聊架构》 书评的笔记 如何学习架构 《反应式设计模式》笔记 项目的演化特点 反应式架构摸索 函数式编程的设计模式 服务化 ddd反模式——CRUD的败笔 研发效能平台 重新看面向对象设计 业务系统设计的一些体会 函数式编程 《左耳听风》笔记 业务程序猿眼中的微服务管理 DDD实践——CQRS 项目隔离——案例研究 《编程的本质》笔记 系统故障排查汇总及教训 平台支持类系统的几个点 代码腾挪的艺术 abtest 系统设计汇总 《从0开始学架构》笔记 初级权限系统设计 领域驱动理念入门 现有上传协议分析 移动网络下的文件上传要注意的几个问题 推送系统的几个基本问题 用户登陆 做配置中心要想好的几个基本问题 不同层面的异步 分层那些事儿 性能问题分析 当我在说模板引擎的时候,我在说什么 用户认证问题 资源的分配与回收——池 消息/任务队列

标签


项目的演化特点

2019年02月20日

简介

最开始,只是一个简单的需求,然后基于简单的需求实现了一个系统。然后不停的开始加小功能,尤其是需求方来自不同的人员的时候,无目的的扩充,会让系统逐步变得很臃肿、零散,中间还往往伴随着 项目负责人的变动,代码风格的不一致等。

项目的演化有两个方向

  1. 广度,觉得系统不错,让它承担更大的职责边界。 尤其要警惕跟系统功能很类似,但本质不是一个东西的需求
  2. 深度

    • 更高性能,数据更全,界面更友好等
    • 项目的各个要素 从特定 变成灵活配置。不仅 项目的职责边界 会变化,某个要素的意涵 与项目设计之初也可能会有所不同。
  3. 在设计一个系统时,必须描述清楚项目的边界和假设。一旦新功能跨了边界,最好是重新设计,而不是很丑陋的兼容实现。 另一个方面,加功能的时候通常只是立足于功能本身,而没有从全局视角来调配问题。辽沈战役中,有一个阻击阵地失守了,连长想夺回阵地再汇报。最后,所属团长撤职,连长枪毙。
  4. 项目必须周期性的调整,基于变化,调整项目的边界。评价项目是否应该重构(以及重构方案的好坏)的重要标准是:项目当前状态与理想状态的差距。

项目本身会腐化、臃肿,越来越多的老代码、历史遗留,最后应对问题的时候越来越力不从心,就好像一个王朝的末期,军事失败只是表象,组织、经济能力失灵才是本质。

一个项目问题的解决是分层次的,比如分布式事务问题:

  1. 可以业务需求、架构层干脆避免分布式事务
  2. 也可以应用层使用相关框架 + 设计解决
  3. 也可以干脆使用大容量或分布式数据库,即在数据库层面上解决。

解决问题时,通常并不是单纯解决问题本身就够了,还要符合整个系统一贯的思路。

一个项目 ,若是长时间不管,不精心培育,关键时刻是顶不住的

项目的发展离不开需求的完备性,但需求是一波波的,不是一个线性的过程。

项目需求变化 ==> 实现方式变化 ==> 使用方式变化 对项目的挑战很大,比如k8s为什么会赢?后Kubernetes时代,2019的容器技术生态会发生些什么?不同于一个只能生产资源的集群管理工具,Kubernetes 项目最大的价值,乃在于它从一开始就提倡的声明式 API 和以此为基础“控制器”模式。Kubernetes 项目为使用者提供了宝贵的 API 可扩展能力和良好的 API 编程范式,催生出了一个完全基于 Kubernetes API 构建出来的上层应用服务生态。可以说,正是这个生态的逐步完善与日趋成熟,才确立了 Kubernetes 项目如今在云平台领域牢不可破的领导地位,也间接宣告了竞品方案的边缘化。

无论如何演化,每个项目都有一个内核

笔者曾经负责过两个项目:配置中心和api管理

  1. 配置中心,一个配置管理系统,app 启动时访问该系统,拉取适配app的所有配置。进而支持运营通过更改配置 来操控 app的行为
  2. api管理,类似swagger,服务端项目开发完毕后,录入接口,供前端/客户端使用,进而支持apimock等功能,支持前后端并行化开发

两种思维方式

  1. ”归纳整理法“。常规的设计系统的流程:研究业界已有系统,提炼抽象,该系统有几个基本概念,每个概念有几种实现方式,然后整理归纳,判断取舍,制定详细设计方案。从这个视角来看,配置中心 和 api管理 是两个完全不一样的系统。”归纳整理法“ 说白了是从众心理,体现在生活上就是这事儿别人做了,所以我也要做。
  2. “核心扩展法”,说白了是第一性原理在系统设计的体现。配置中心有项目、分组、配置、发布等概念,api 管理有项目、模块、api、mock 等概念。换个表达方式:api管理首先是做接口管理的,然后因为接口不能平铺在那里,所以从组织方式上有模块管理和项目管理。接口是人操作的,所以有权限管理,然后围绕接口有api mock 等。 从这个角度看,api 和 配置中心是一样一样的,url 类似配置中心的一个个配置。

我们为什么要争辩两个思维方式的差异,就是因为常规的”整理归纳“的思维方式,无法帮助你在一些具体的问题上做决策,你最多知道一个具体的特性在你调研的案例里有几个实现了,有几个没实现,这个问题在”核心扩展法“思维下就很好决策,既然项目都有一个内核, 那么项目迭代的过程中,一定要关注对内核的影响。比如当你去看业界主流的api 管理系统实现时,不能被外在的项目公有/私有,是否支持模块 等这些细节所迷惑,它的核心是做api 管理,其它一切都是围绕接口管理进行的。你向别人介绍自己的项目时,也应该先从接口管理入手,这是要点,然后才是其它”支持“功能。

时刻保持优雅,而不是修修补补成大泥球

业绩增长常会稀释人才密度,当业务复杂度往上快速增长时,公司高绩效人才的占比是下降的,两者会出现一个交叉点。当交叉点出现时,你会发现以前的那套流程已经不适用了,混乱和错误开始出现,产品迭代速度会受到严重制约。在这个人才密度上,业务已经变得太过复杂,而系统不可能再以往常的形态运行。

需要完善团队人才梯队,使人才密度的提升超过业务复杂度增长。

项目管理

做产品想“多快好省”都占着,是不可能的,最多只能选两样。因为软件工程的目标就是要构建和维护高质量的软件,“质量”这个因素一般不会妥协。PS:与分布式CAP异曲同工之妙

固定一条边很重要:从时间、成本和范围这三条边中找出来固定的一条或者两条边,再去调整另一条边。

“不可能三角”是道的层面,应用在“术”的层面:

  1. 老板要压缩工期,则应减少产品范围和加大成本(投入更多人力)。
  2. 产品经理要临时加需求,则要么延期要么加人。
  3. 这些年流行的 MVP((minimum viable product,最小化的可行性产品)模式,是一种快速推出产品的模式:一开始只推出最核心的功能,满足用户最核心的需求,然后在用户的使用过程中收集反馈,进一步升级迭代,快速试错。

这个世界上有好多事情,看着像可以任意发挥, 但又不能任意发挥, 那么这个边界在哪里?就到你要摸索每个问题域的本质。

《软件架构设计》:对于项目管理,有一个关键问题要面对:“不确定性”问题。从人的认知来讲,做任何事情,思路都是从一个“朦胧”到逐步“清晰”的过程,项目的进展也是一个从思路、到方案、到落地的细化过程。在这个过程中, 不可避免存在“不确定”,比如需求变化、新技术生疏、核心人员离职、与其它部门协调、历史遗留等,项目管理就是要提前防范各种不确定性。