演进式架构学习笔记（一）：架构评估及适应度函数

适应度函数，本质上就是一组评估函数，用以评估架构在不同维度上的表现，并从全局角度进行平衡，从而实现增量和引导式演进。简言之，其实就是能够构建出一套架构监控机制。

适应度函数，并不一定全部采用自动化手段，甚至某些维度不可能采用自动化手段。评估函数的确定，和问题域密切相关。需要识别出关键维度和相关维度。

架构特性---适应度函数----探索式架构设计

工程效率提升（CI）----这里联想到百度的工程效率部。

微服务架构，让我联想到Erlang的进程，所有进程都是独立的，相互不耦合，仅仅通过消息进行通讯。此处的进程并不是操作系统进程，而是虚拟进程。这让版本升级异常简单，甚至可以实现不中断服务的热升级。而微服务架构，只是这种思维的一种特别版本。服务是单独的进程，运行于Docker容器中，服务本身也支持了横向伸缩。需要彻底了解：微服务和WebService到底有何区别？

如何评估架构的长期有效性？一个架构，只有经过设计、实现、测试、升级和变更这个生命周期之后，才能得到有效评估。简言之，只有真正在暴风雨中生存下来的，才是具有长期演化可能的架构。

那么如何评估呢？除了无法避免的手工评估手段之外，自动化评估工具集是更关键性的手段，而如果要做到自动化，则可测试性必须在架构设计时给予充分的考量和设计。也就是说，可测试性本质上是需要设计的。自动化评估最大的优势是可以根据需要灵活调整其运行的时间、频率，并可以重复执行。

假设驱动开发是个颇有创意的思路。它避免了依赖于单个BA或者市场人员对需求的把握，而是通过技术手段，采用不同策略并行的方式，继而通过统计来从用户行为中学习，从而构建出更有价值的系统。本质上假设驱动开发仍然属于反馈环，用户亦作为反馈环的重要环节参与其中。假设驱动开发可以使用的技术手段很多，比如微服务中，可以通过服务路由来确定哪些服务最被常用；比如传统软件中，通过增加用户操作日志来采集用户行为并对其进行分析。