1、概述
本文次要分三局部，第一局部简要论述“演进式架构”和“适应度函数”的概念，其中局部内容节选自《演进式架构》一书；第二局部通过以 etcd 和 kubernetes 为例阐明演进式架构思维如何影响开源我的项目的演进；第三局部通过对第二局部的思考总结，进而推演出在公司软件产品的开发过程中，咱们该如何借助“演进式架构”的思维更好地迭代现有软件产品。
2、概念 演进式架构
软件行业已经有这样一个共识，架构一旦确定，“日后很难扭转”。演进式架构将反对增量式变更作为第一准则。因为从来变更都是很难预测的，革新的老本也极其低廉，所以演进式架构听下来很吸引人。如果真的能够在架构档次做到演进式地变更，那么变更就会更容易、老本更低，也能产生在开发实际、公布实际和整体麻利度等多个中央。
大泥球架构 — 来自一个不愿透漏名字的我的项目
适应度函数疏导演进式架构
完满的零碎？
自有软件系统以来，诞生了有数的优良的零碎改善了咱们的生存，有些零碎甚至曾经被继续应用过了数十年。
然而，有没有零碎自打诞生之初就是完满的呢，答案必定是没有的。例如下图展现了 Linux 自 1991 年以来所进行的迭代版本的 timeline，甚至曾经有上百个版本。
软件系统的进化永远是一个衡量的后果。
经典物理学 vs 控制论
以往在构建软件系统时人们总是尝试在我的项目打算初期，尝试制订一个靠近“完满”的打算，而后在很长一段时间内遵循这个打算，埋头苦干，直到最后的打算实现。
这个过程就像是在发射一颗迫击炮弹或是其余无被动动力系统的炮弹：在发射炮弹之前，通过计算发射终点和起点的绝对间隔、海拔，如果准确一点再加上风速，依据牛顿运动学定律算出一个初始角度，点燃炮弹。炮弹升空后，所有就事在人为了。如果中途风速变了，或是指标物长期挪动了一下，炮弹都会打偏。对应这套基于经典物理学的导弹系统来说，间隔越远，偏差肯定也越大。
现代化和平中应用的准确制导导弹则应用的是齐全不同的策略。导弹本身携带动力系统和技术零碎，实时计算反馈以后速度、地位与指标的间隔，而后动静调整角度和速度，最终准确打击目标。这套基于控制论的形式将导弹的精确度
由此尝试在软件畛域引入控制论中这套实时计算反馈的办法，即适应度函数（零碎函数）的概念，通过一直对系统关注指标进行量化测试来准确的管制
影响软件我的项目的掂量指标可能有很多，如代码品质、性能、稳定性、复杂度、开发效率、安全性、可扩展性、可审计性等等。这些每一个指标都能够有对应的适应度函数。
总体大于局部之和，全面的去过于关注某一个维度的适应度函数并不能带来很好的收益。项目经理或架构师须要联合各个维度的适应度函数制订一个全零碎适应度函数，来为后续架构决策作为领导。
适应度函数不拘泥于特定模式，它可能是主动的，如单测覆盖率、零碎性能测试，也可能是须要手动评估的，如零碎复杂度等，但它肯定是须要可量化的。下图给出一个全局适应度函数的示例。每个指标满分为 5 分，最低分为 0 分。
从图中能够大抵评估出该零碎在数据安全性、高性能等方面比拟优异，但在易用性、可审计性等方面较弱。零碎演进方向肯定是补足评分较弱的方向，但根据零碎定位不同，也不是所有评分较低的我的项目都须要补齐。假如该图是为某银行开发的外部管理系统，那么相比晋升零碎响应工夫和易用性，可审计性的要求优先级肯定更高一些，因而下个阶段的开发指标可能是先晋升零碎可审计性。由此可总结出适应度函数的两个次要作用：
- 评估零碎现状
- 制订下个开发周期的工作优先级和总体目标。
不同类型的我的项目、产品关注的指标可能不尽相同，以下简要列出开源我的项目和商业软件产品所关注的一些指标。
开源我的项目的适应度函数相干指标
- 性能完整性
- 稳定性
- 可扩展性
- 安全性
- 高性能
- 伸缩性
- 受欢迎度
- 易用性
商业软件产品的适应度函数相干指标
- 性能完整性
- 稳定性
- 可扩展性
- 可观测性
- 高性能
- 安全性
- 易用性
- 研发 ROI
- 创新性
-
产品销量
3、开源我的项目的演进
每个适应度函数都应该是可量化的，但受篇幅限度，不在此开展讲每个指标的适应度函数的具体计算方法，只讲零碎演进变动和全局适应度函数的关系。
ETCD 演进
诞生
2013.8
ETCD —> Distributed etc，分布式配置管理系统，类比单机的 linux etc
CoreOS 团队须要一个协调服务来存储服务配置信息、提供分布式锁等能力供其分布式容器管理系统应用。
为什么造轮子
需要剖析：
- 反对 watch 方便使用方及时收到告诉响应
- 部署运维简略：因为设计之初假设分布式系统不稳固，所以该分布式系统应反对频繁增删节点
- 高可用与一致性（CP）
- 应用形式简略通用，不与语言绑定
- 仅存储元数据因而无需反对太大数据量 (MB 至 GB 级别即可)
计划比照
zookeeper：
- 功能性需要满足
- 调用简单
- 部署简单，过后无奈不重启的状况下增删节点
自研：
参考已有计划，隔靴搔痒。
- http 长连贯 watch
- raft 保障 CP 和容灾
- REST API 简略
- 数据结构应用内存树，满足需要，暂不思考长久化问题
roadmap
v1
keyword: it works
应用 golang 实现了基于 REST 的配置根本的 CRUD 性能，直观易用。
满足 CoreOS 根本的需要，在外部开始应用。
第一个版本在易用性方面较为优良，高性能方面对于单机利用来说根本合格，一方面为技术栈特点决定，另一方面因为性能也还比较简单。但其它各方面都还比拟弱，未实现残缺的 RAFT 导致伸缩性还无奈实现、暂无平安校验。
v2
keyword: 填坑
因为要在大规模生产集群应用，在 v1 开发完不久后，coreOS 团队着重对目前较弱的性能完整性、安全性等影响生产环境采纳 etcd 的性能进行了大幅欠缺，具体欠缺的内容可参考如下脑图。
这其中几个外围点:
- 高可用
- 读一致性
- 目录构造
因为 v2 满足了 kubernetes 对元数据存储的需要 (Go 语言编写、etcd 高可用、Watch 机制、CAS、TTL 等个性)，被 kubernetes 社区宽泛应用，导致我的项目受欢迎水平大幅晋升。
v2 版本的 etcd 零碎全局适应度函数如上图所示，除了性能和稳定性、扩展性外，均有了较高的评分。至此，etcd 曾经孵化成了一个较胜利的开源项，后续需在稳定性、性能方面投入更多精力。因为拓展性并不是较重要的零碎指标，所以暂未进行相干降级迭代。
v3
keyword: 性能优化，稳定性，提醒用户体验
“不被应用的零碎永远不会有 bug，也不会被吐槽。”
“我的项目被吐槽是坏事，因为阐明有人在用。”
随着 Kubernetes 我的项目一直倒退，v2 版本的瓶颈和缺点逐步裸露，遇到了若干性能和稳定性问题，Kubernetes 社区呐喊反对新的存储、批评 etcd 不牢靠的声音开始一直呈现。
这个阶段实现的外围性能如下：
- gprc
- 勾销目录构造
- 分页
零碎完整性、稳定性、性能进一步优化，但随着零碎变得越来越简单，零碎肯定会失落肯定易用性，但好在还在可承受范畴内。
至此，etcd 各方面曾经是一个较成熟的开源我的项目了。
etcd 从最的公司外部我的项目，到最初疾速成长为领有 3w 多 star 的胜利的开源我的项目，每一个版本都粗浅汲取了社区反馈，并抓住过后外围问题进行欠缺，是一个很值得借鉴的例子。
k8s 演进
诞生
https://storage.googleapis.co…
2014 from Borg
borg
Birth: 2003
Arch: Cell[borg master — borglet — scheduler]
Lang: C++
外围性能:
- Pod
- Service
- Label(加强)，borg 中只有 task 和 job，k8s 的 label 性能能弱小
IP-per-Pod，隔离更彻底，可选不绑定宿主机 ip 和端口，升高运维复杂度
2015 v1.0
keyword:startup, cncf
自 v1.0 甚至更早版本开始，google cloud 就同步推出基于 kubernnetes 开源版本的 SaaS 服务，在生产环境验证了这套计划的可行性。
因为 Kubernetes 是 Google 外部十几年积淀后开源的我的项目，所以自我的项目 1.0 开始就有较好的性能完整性。同时，其分布式架构人造决定了它有不错的伸缩性，能反对单集群上百节点。相比于同期间的其余容器治理计划，诸如
swarm、docker-compose，kubernetes 因为其复杂性，在易用性上体验还有待晋升。总体来说还是比拟平衡的。
2016 v1.2 – 1.5
keyword: enhancement、Ease of use
- scaling
- rollingupdate
- automated cluster management
- node hardware awareness
- Helm
- MiniKube
- kubeadm
做了很多有助于升高零碎应用复杂度、体验老本的工作，因而整体易用性失去了晋升。
2017 v1.6 – v1.9
keyword: enterprise features，security
- local storage
- secret encryption
- RBAC
针对大规模在企业中利用时遇到的企业级个性进行了加强。
2018 v1.10 – v.13
keyword: extensibility
- Storage class(CSI)
- containerd(CRI)
- In-Cluster Service Load Balancing(IPVS)
- TLS Bootstrapping
- API aggregation
- Interface 化，在可扩展性方面有了大幅晋升（指达到 GA 版本，有些性能在之前版本曾经有 alpha、beta 版 )
2019 v1.14-v1.17
keyword: extensibility
- CRD improvement
- Admission Webhook improvement
- schedule framework
- kubeEdge
- kubectl plugin system
继续优化可扩展性，以及整个生态的构建。
2020 v1.18-1.20
keyword: function completeness
- ServerSide Apply
- Topology Aware Schedule
- hierarchical namespace
- TLS rotation for kubelet
一些功能性补全。
上图能够看出，2015-2020，整个 kubernetes 生态已逐步完善，成为了容器治理的事实标准。与 etcd 相似，其 roadmap 中每个版本的外围性能，都是有针对性地对上一次全局适应度评估中的弱项进行的补齐，最终成长为一个胜利、成熟的开源我的项目。
商业软件产品的迭代
商业软件产品和开源我的项目的异同
一般来讲，商业软件产品的适应度函数要比开源我的项目的更简单些，因为除了我的项目自身，还要掂量老本、市场相干的指标，可体现为如下指标：
- 研发 ROI
- 创新性
- 产品销量
根据适应度函数适时对我的项目进行评估，能对产品现状有更好的认知，也能对将来工作有更可持续性的布局。在外界环境发生变化时，也能率领团队做出调整疾速响应。
落地
TODO 每个指标的量化，以及如何和 pipeline 联合，是个比较复杂的问题，在后续文章中展开讨论。