标签：学习 作者 模型 读者 应该 不用 写代码 负载均衡 出现
序
本书是《架构即未来》的姐妹篇，作者译者还是一样的，味道没变，如果《架构即未来》讲的是“艺”，那么此书将的就是”术“。
书中对于《架构即未来》的一些概述进行了讲解，虽然不算全面，点到即止，给了读者相应的空间自己去理解、实践，每条规则都相当实用，质量确实不错，干货满满。
心得
技术类的文章看完之后，更多的应该是进行实践，自己亲身去应用，感受组合不同技术时遇到的困难和解决困难带来的快乐，而不是只停留在看上面。
比如当单进程系统即将超载时，通过X轴扩展加入负载均衡（但是如果机器处在不同的网段，这又是另外的难题了^_^），增加吞吐量、提高可用性和灵活性，此时就会遇到为什么要尽量保持无状态了，集群中保持请求的状态难度大而且复杂；于此同时随着机器的增加，故障率也会有所上升，运维、排查故障的复杂程度也会加大，适时引入日志系统，当出现错误的时候将日志记录下来，如果是用分布式的日志解决方案的话，处理起来会减少很多不必要的麻烦(但是却失去了理解一些其他技术使用的场景)，如果选择存储在本地，那么面临的一个问题是，那么多的机器，那么多的错误日志，需要使用日志的时候，让人工一台一台机器去查看简直要命，这时可以根据使用场景的不同进行设计，虽然可以从网上借鉴一些成熟的解决方案来使用，但是也不要忘了去理解成熟解决方案的机制（能学习到不少技术、经验），对于的日志处理，在需求明确的情况下，必定能得出一个具体的业务模型，那么就可以对日志进行自动分析了，使用数据库来存储分析的结果，就不用每次查看日志的时候再重复分析了。然后是对机器的监控(内存、cpu、io等)、api的监控(耗时、错误率、频率)等，从开发到测试再到运维，关注点越多，需要人工操作的地方越少，项目的稳定和可用性就越高。
以上的例子就已经包含了50条规则中的其中几条了，技术无所不在，走一些捷径势必会失去一些成长的机会，多写代码，代码的质量要提高。
标签：学习 作者 模型 读者 应该 不用 写代码 负载均衡 出现
原文地址：https://www.cnblogs.com/ahl5esoft/p/8757038.html
