读书笔记《持续演进的Cloud Native》

架构是锤炼出来的，而不仅是设计出来的。优秀的人不愿意来，不一定是因为钱。花钱雇佣优秀的人是一方面，怎样管理这些人又是另外一方面，用管理搬砖者的方式来管理他们是不行的，管理优秀的人需要给予他们更多的信任，需要营造一种公开透明、自由高效的环境。观察任何一个企业都可以从三个角度出发，这三个角度分别是技术、流程、文化。从架构的角度讲，为失败设计同样重要，因为失败是不可避免的，我们希望失败的结果是我们预料到的，是经过设计的。为了提升可用性，我们应该尽量减少故障修复时间，要知道替换的速度远远快于修复的速度。如果你发现设计满足了所有的要求，说明你一定过度设计了。当业务复杂度达到一定程度后，微服务架构消耗的成本才会体现优势，并不是所有的场景都适合采用微服务架构，服务的划分应逐步进行，持续演进。产品初期业务复杂度不高的时候，应该尽量采用单体架构。通常业界用牲畜来比喻无状态，用宠物来比喻有状态。宠物是需要呵护的，是有名字的，不能被轻易替代的，而牲畜是没有名字的，只生产肉和奶，死掉一个用新的来替代即可。所以，我们期望服务可以做到无状态，可以被轻易地替代。接口应该作为唯一对外提供的访问方式，这代表的是控制力。解决方法就是通过接口调用，逐步去除数据库的直接访问。一个普通的RPC调用过程：（1）客户端在业务服务中发起请求。（2）调用本地stub，本地stub对消息进行序列化、封装等处理。（3）客户端stub调用网络通信模块将消息送达服务端，中间还可能包括寻址、建连接等一系列操作。（4）服务端网络通信模块把接收到的消息转发给stub进行反序列化。（5）stub转发给业务服务进行处理并返回结果。（6）stub将结果进行序列化，调用网络通信模块。（7）服务端通过网络通信模块将结果返回到客户端网络通信模块中。（8）客户端网络通信模块将消息转发给stub。（9）stub进行反序列化并转发给客户端业务服务。（10）客户端得到最终结果。目标是让（2）到（9）对开发者不可见。平台可以提升团队的下限，让平凡的业务开发人员做出不平凡的系统。海恩法则指出：每一起严重事故的背后必然有29次轻微事故和300起未遂先兆，以及1000起事故隐患。Code is easy, state is hard.不沟通才是最有效的沟通。什么样的团队结构，就会设计出什么样的系统架构。......