Context

《发布!软件的设计与部署》这本书终于读完了,不过我感觉我现在的水平还有很多内容没有理解。所以这本书,我总还要找机会搞来的!

Chapter

这剩下的两节都是第四部分:运营 的内容,帮助

透明度

透明性是指这样一种特性,它能让操作员、开发者和商业赞助商理解系统的历史趋势、当前状态、瞬间状态和未来设想

如果系统的透明性很差,那么即便我们发现系统出现了异常或者故障,也很难快速的找到问题的根源。按照我的猜想,透明性大概就是在系统的各种关键点(继承点)增加控制接口、log记录等。因为在遇到问题的时候,知道的信息越多,定位问题越方便;组件提供的接口越多,操作起来越方便。

想一下,如果好不容易发现了问题,结果这个问题的解决方法只能通过修改系统代码(更新软件)来解决,那实在是太痛苦了;如果一个系统中很多的操作都是根据配置文件来确定的,那只要修改了配置文件,并重启服务(软件),那么问题就解决了,岂不是爽歪歪。

没有透明性的系统不能在生产中长期存在。如果管理员不知道它正在做什么,就不能调整和优化。如果开发者不知道在生产环境中什么能行什么不行,就不能对它进行增强和更新

这一章从4个层次解释了透明性:历史趋势、未来预测、当前状态、瞬间行为。

历史趋势很有意思,作为一个初等程序员,对于历史问题,我可能只会关心什么时候产生错误警告,错误警告产生的原因,触发条件这些东西。而资深架构师运营经理总是可以问一些小白、普通程序员不会想到的问题。比如:我们昨天有多少订单;第一季度我们使用了多少磁盘空间;过去三年顾客流量的增加和CPU使用率增加相比的结果~

当我们觉得没有看到警告,没有看到错误就心满意足的时候,他们总是可以想的更加长远(现在我也可以想的更长远啦~)

当前状态简单说,就是要给出足够的数据来反映系统运行的状态,产生了多少报警,多少异常,内存用了多少,还剩多少,线程数量,可用线程、繁忙线程、等等等等。不能让系统运行的像个薛定谔的猫一样。说到这里,作者也提到了日志的规范性,不能说有了日志就大功告成了,日志要分级,要有良好的格式,让人阅读的方便。不然几万几万的日志,即使知道关键内容在里面,也会让人失去探索的兴趣。

适应

适应性差不多就是兼容性的意思。系统在不断的被完善,老用户如何适应新系统,新系统如何适应老用户。开发人员如何用更低的成本去维护系统,去更新系统。这就是这一章的主要内容。

依赖注入,对象设计,极限编程实践,敏捷数据库,这是适应性软件设计的四个方法。简单的说他们都在鼓励松耦合,高内聚,提高向下兼容的能力。

发布应无害 讲到了’部署成本太高零停机时间部署`和其他的几点。这两点单独拿出来说,是因为,颠覆了我的认知~

本以为部署一个系统多容易啊,改了新的代码,重启服务即可,有什么成本呢?实际上专业的团队在部署的时候,需要创建发布分支,发布说明文档,与营销沟通,计划执行验证部署,后续的技术支持。这些都是人力成本~

平时看到停机维护的情况比较多,所以对零停机时间部署这个概念还是比较好奇的。说的是,部署行版本,可以一步一步慢慢来,按阶段分解部署,不是立刻添加改变删除一些东西。增加各种兼容性。

Addition

上一篇中没有说到 快速失效 ,在第18章《适应》中讲到了一个例子,让我猛的想起了这个有用的设计~

比如,一个请求,我们其实早就知道,这个操作可能要出现错误了,却还是让请求做到了出现异常的时候,才反馈。就相当于客户白等了很久得知,自己想做的事情不能被达成。所以快速失效可以相当于做一些中间件吧~提前做一些处理,早就知道要失败了,就直接返回,不再继续执行操作。

End

这本书终于读完了,我肯定还会再搞来的!现在觉得一些书看不懂,没意思,说不定并不是书的问题,而是自己段位太低了~哈哈

(每次写一篇博客,都会晚睡一次~)