智能端点与哑管道
在单体应用中，组件间直接通过函数调用的方式进行交互协作。而在微服务架构中，由于服务不在一个进程中，组件间的通信模式发生了改变，若仅仅将原本在进程内的方法调用改为RPC方式的调用，会导致微服务之间产生繁琐的通信，使得系统表现更为糟糕，所有，我们需要更粗粒度的通信协议。
在微服务架构中，通常会使用以下两种服务调用方式：
- 第一种，使用HTTP的RESTful API或轻量级的消息发送协议，实现信息传递与服务调用的触发。
- 第二种，通过在轻量级消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的中间件。
去中心化治理
当我们采用集中化的架构治理方案时，通常在技术平台上都会制定统一的标准，但是每一种技术平台都有其短板，这会导致在碰到短板时，不得不花费大力气去解决，并且可能因为其底层原因解决得不是很好，最终成为系统的瓶颈。
在实施微服务架构时，通过采用轻量级的契约定义接口，使得我们对于服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中各个组件就能针对其不同的业务特点选择不同的技术平台，终于不会出现杀鸡用牛刀或是杀牛用指甲钳的尴尬处境了。
整理了一份Java核心知识点。覆盖了JVM、锁、并发、Java反射、Spring原理、微服务、Zookeeper、数据库、数据结构等大量知识点。基本上涵盖了Java架构所有的技术知识点的资料，还覆盖了大厂面试题，同时也有一些springboot等项目源码分享给大家
由于资料图片太多就不一一的展示出来了
还有最全免费的大厂面试题
去中心化管理数据
我们在实施微服务架构时，都希望让每一个服务来管理其自有的数据库，这就是数据管理的去中心化。
在去中心化过程中，我们除了将原有数据库中的存储内容拆分到新的同平台的其他数据库实例中之外（如把原本存储在MySQL中的表拆分后，存储到多个不同的MySQL实例中），也可以将一些具有特殊结构或业务特性的数据存储到一些其他技术的数据库实例中（如把日志信息存储到MongoDB中或把用户登录信息存储到Redis中）。
虽然数据管理的去中心化可以让数据管理更加细致化，通过采用更适合的技术可让数据存储和性能达到最优。但是，由于数据存储于不同的数据库实例中后，数据一致性也成为微服务架构中亟待解决的问题之一。分布式事务本身的实现难度就非常大，所以在微服务架构中，我们更强调在各服务之间进行“无事务”的调用，而对于数据一致性，只要求数据在最后的处理状态是一致的即可；若在过程中发现错误，通过补偿机制来进行处理，使得错误数据能够达到最终的一致性。
基础设施自动化
近年来云技术服务与容器化技术的不断成熟，运维基础设施的工作变得越来越容易。但是，当我们实施微服务架构时，数据库、应用程序的个头虽然都变小了，但是因为拆分的原因，数量成倍增长。这使得运维人员需要关注的内容也成倍增长，并且操作性任务也会成倍增长，这些问题若没有得到妥善解决，必将成为运维人员的噩梦。
所以，在微服务架构中，务必从一开始就构建起“持续交付”平台来支持整个实施过程，该平台需要两大内容，缺一不可。
- 自动化测试：每次部署前的强心剂，尽可能地获得对正在运行的软件的信心。
- 自动化部署：解放繁琐枯燥的重复性操作以及对多环节的配置管理。
容错设计
在单体应用中，一般不存在单个组件故障而其他部件还在运行的情况，通常是一挂全挂。而在微服务架构中，由于服务都运行在独立的进程中，所以存在部分服务出现故障，而其他服务正常运行的情况。比如，当正常运作的服务B调用到故障服务A时，因故障服务A没有返回，线程挂起开始等待，直到超时才能释放，而此时若触发服务B调用服务A的请求来自服务C，而服务C频繁调用服务B时，由于其依赖服务A，大量线程被挂起等待，最后导致服务C也不能正常服务，这时就会出现故障的蔓延。
所以，在微服务架构中，快速检测出故障并尽可能地自动恢复服务是必须被设计和考虑的。通常，我们都希望在每个服务中心实现监控和日志记录的组件，比如服务状态、断路器状态、吞吐量、网络延迟等关键数据的仪表盘等。
演进式设计
通过上面的几点特征，我们已经能够体会到，要实施一个完美的微服务架构，需要考虑的设计与成本并不小，对于没有足够经验的团队来说，甚至要比单体应用付出更多的代价。
所以，在很多情况下，架构师都会以演进的方式进行系统的构建。在初期，以单体系统的方式来设计和实施，一方面系统体量初期并不会很大，构建和维护成本都不高。另一方面，初期的核心业务在后期通常也不会发生巨大的改变。随着系统的发展或者业务的需要，在架构师会将一些经常变动或是有一定时间效应的内容进行微服务处理，并将原来在单体系统中多变的模块逐步拆分出来，而稳定不太变化的模块就形成一个核心微服务存在于整个架构之中。
