yabocui

后微服务时代（云原生时代）：软件和基础硬件设置一起解决分布式架构遇到的问题

总结：远程服务调用（RPC）为了做的像使用IPC那样，对研发透明，需要解决三个问题：参数如何标识，数据怎么传输，怎么定位方法。没有最好的RPC框架，只有合适的RPC框架，每种RPC框架在在某些方面做了取舍

总结：和SOA比起来微服务非常的灵活，没有复杂的标准，但是对于架构者来说，将架构能力要求提升到了史无前例的程度，架构者需要做权衡，做取舍。微服务有以下特点： 1、围绕业务能力构建，有什么样的规模、结构、能力的团队就会产生什么样规模、结构、能力的架构。 2、分散治理：各个团队负责自己的服务。 3、通过服务实现独立自治的组件。 4、产品化思维：产品不但迭代 4、数据去中心化：数据不在保存在一起 5、强终端弱管道：通过restfule实现通信 6、容错性设计：正视服务总会出错，做好服务的检测、熔断、恢复和重新联通。 7、渐进式设计：承认服务会被淘汰 8、基础设施自动化

总结：单体架构并不是一个贬义词，具体要结合业务来看待，如果业务比较简单一个单体应用就可以搞定，那就完全没有必要用分布式。大型单体应用的弊端：1、在一个进程中，如果某个函数有问题导致oom那么整个系统就挂了；2、不能做到滚动升级；3、异构语言困难；单体应用之所以被分布式取代并不是因为上面说到的原因，而是随着业务越来越复杂，交付一个可靠的单体系统越来越具有挑战性

大型单体应用拆分经历了以下几个环节：烟囱式架构，将大型单体系统拆分成几个完全独立的系统，但是这个不太可行，因为完全独立不太可能，最起码用户之类的信息是共享的。插件式架构：将系统需要用到的服务抽取成核心系统，例如用户体系，其他系统以插件的形式和用户体系通信，缺点是插件之间无法互相调用。事件驱动架构：各系统之间以事件的方式通信。面向服务的架构（SOA）：昙花一现，不具有通用性，脱离人民群众

总结：因为早起单个计算机性能的限制，分布式架构比大型单体架构出现的更早，科学家为了做到像单体应用一样方便的使用分布式架构做了很多努力，但最后失败了，但是在这个工程中收获颇丰

总结：无服务有两部分组成后端设施和函数，后端设施指的是一些通用的组件直接使用云上的，函数指的是业务代码，可以很小，小到和代码中的函数差不多