sssssssssnake的博客

比如A类的加载器是AppClassLoader(其实我们自己写的类的加载器都是AppClassLoader)，AppClassLoader不会自己去加载类，而会委ExtClassLoader进行加载，那么到了ExtClassLoader类加载器的时候，它也不会自己去加载，而是委托BootStrap类加载器进行加载，就这样一层一层往上委托，如果Bootstrap类加载器无法进行加载的话，再一层层往下走。从上面贴出的Class类的构造方法源码中，我们知道这个构造器是私有的，并且只有虚拟机才能创建这个类的对象。

它的出现促进了优先对象模型的服务方法，定义了服务责任和绑定的数据模型。正确的拆分对提高系统的容量有很大的帮助，失败的拆分可能会造成热点集中，得不偿失。场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。它提供更快的交付服务、跨数据的可见性和具有成本效益的数据。当你修改了一个边角的小功能，但是你不敢马上上线，因为你依赖的其他模块才开发了一半，出现大量「功能耦合」，那么这个微服务就需要拆分了。

保留在单体中的类可能会引用已移动到服务的类，反之亦然。使用主键替换对象引用的一个问题是，虽然这是对类的一个小改动，但它可能会对期望对象引用的类的客户端产生很大的影响。如果是这样，那么你的救星来了，如果从当前窘境中脱离，实现我们的微服务，从而完成我们的升级。你需要通过将单体中的功能提取到服务，从而将单体中的功能迁移到绞杀者应用程序。因此，你可以将 Order 和 Restaurant 类视为聚合，如图所示，将Order类中对 Restaurant 的引用替换为存储主键值的restaurantId 字段。

基于云端组建的基础资源，包括数据库、缓存和文件系统等，这些资源既可以使用云服务提供商提供的优质 RDBS 、分布式数据库和对象存储等服务，也可以自己搭建各种集群体系。这是一个典型的微服务总体架构设计图，自上往下看，可以分为前台应用层、 API 接入层、业务应用层、服务中心和基础资源层结构，每层结构都有其自身的功能和特别的设计。如图 2-4 所示，是根据阿里云设计的一个安全管理架构，通过安全防护和安全预警 对不安全的访问或可能存在的攻击进行有效隔离，从而保证系统的安全和稳定。

有同步请求/响应通信机制，例如基于 HTTP 的 REST 或 GraphQL，或 gRPC。或者可以使用异步的、基于消息的通信机制，例如 AMQP（高级消息队列协议）或 STOMP（简单/流式面向文本的消息传递协议）。此外，还有许多不同的消息格式。改进了客户端-服务器交互，使前者能够进行精确的数据请求，并只获得他们需要的数据。基于消息的应用程序通常使用像 RabbitMQ 这样的消息代理，充当服务之间的中介。微服务的通信模式，通信是保证服务请求核心要素，选择合适的一个通信协议对系统来说可以达到事半功倍。