“微服务体系结构”是当前编程中流行的概念，将来可以与最新趋势同步。 我也为了理解这个架构而学习了。 具体来说，我一直在寻找利用Spring用Java实现微服务架构的方法。
为什么我会有这个想法，这有背景。 我们公司很好，但是有过时的技术堆栈，很少使用Java 8和微服务。 所以我想知道关于微服务的事情，必须自己集中学习。 因此，我做了一个记录我学习经验的待办事宜系统，以供将来参考
概要
本文的目的是为不同的微服务提供源代码演习，不深入解读概念和工具，主要介绍开发微服务的包括模型、工具和技术在内的应用实例。
因为是参考APP应用，所以尽量简化，使源代码更容易理解。在本文中，这个待办事宜系统APP应用由八个部分组成。
Reminder
用户
服务发现服务器
梅勒
自动服务器
系统集成测试
API网关
网络应用客户端
系统如何与微软服务进行交互
上图显示了用户访问使用Angular 2创建的web APP的系统与所有微服务的交互。 然后，连接到OAuth许可服务器。 OAuth许可服务器是分配用户和权限的中心点。 该服务器返回一个包含客户端及其权限信息和格式范围的JSON Web令牌。 一旦用户经过验证并且有令牌，web APP应用程序就会与API网关进行通信。 使用JWT检查是否来自许可服务器，然后调用微服务器来构建响应。
OAuth服务器使用用户服务获取用户的认证详细信息。 API网关还使用OAuth服务器获取用户的信息。
维修服务由待办事宜功能提供。ToDo服务有计划工作，检查通过使用Kafka事件通知服务触发的邮件服务发送的用户，并通过电子邮件进行通知。
系统集成测试是一个到达警报服务端点的Java APP应用程序。
连接到微服务
微服务体系结构需要处理在不同IP和端口上运行的许多微服务器。 因此，需要找到一种不需要硬编码来管理每个地址的方法。
这需要Netflix Eureka。 Netflix Eureka是一种客户端服务发现，允许自动发现和相互通信服务。 系统中使用了Spring Cloud Eureka。 找到Eureka运行服务的位置后，可以添加实例，应用负载平衡，在微服务器之间分配传入的APP通信量。
系统使用Netflix Ribbon作为客户端负载平衡器，以提供容错能力和冗余性，从而提高可靠性和可用性。 使用Netflix Foreign创建声明性REST客户端，并将Ribbon和Eureka集成以提供负载平衡HTTP客户端。
我们的系统有一些依赖。 使用Netflix Hystrix断路器将APP与依赖性故障隔离。 阻止级联故障，以实现备份的快速恢复和添加。 Hystrix为每个依赖关系维护线程池，如果线程池用完，则拒绝请求。 它还提供断路器功能，停止对依赖关系的所有请求。 也可以在请求失败、拒绝或超时时实现替代逻辑。
认证
无论开发什么类型的系统，安全性都非常重要，微服务体系结构也不会改变。 “如何维护微服务的安全性？ ’这个问题出来的时候，我的第一个答案是OAuth2。 OAuth2绝对是一个优秀的解决方案。 是众所周知的许可技术，在谷歌、脸书和Github上广泛使用。
当然，没有Spring Security的话，就不能谈安全。 讨论分布式系统的安全性时，Spring Security和OAuth2是明显的选择。
但是，我们在安全问题上添加了一个叫做JSON Web Token(JWT )的元素。 如果只使用outh，则需要OAuth认证服务器来验证用户、生成令牌、充当资源服务器的端点，并询问令牌是否有效以及授权的权限。 这需要与许可服务器相比增加一倍的请求。 JWT提供了一种向访问令牌传输权限和用户数据的简单方法。 如果所有数据都在令牌字符串中，资源服务器就不需要请求令牌检查。 所有信息序列化为JSON，用base64编码，最后用专用RSA密钥签名。
可以看到OAuth2许可服务器(OAuth-server )和资源服务器) API网关)的代码实现。
里斯特
系统有同步和异步两种方法。 异步，我们使用分布式事件和Kafka遵循了发布/订阅模式。 支持了同步、JSON和XML的rest风格。
Martin Fowler认为，rest风格分为4个级别：级别0 -级别3。 我们的微服务在二级
，为了简单起见，这里不使用HATEOAS设计模式实现超媒体控件。因为我们使用了Spring Cloud，所以必须实现开箱即用的可扩展性模式，将其放在HTTP连接中，例如：断路器，负载平衡，连接池，超时和重试等。
分布式事件
如上所述，我们通过使用Kafka 进行提醒服务和 Mailer服务之间的通信，并异步地与其他Microservices进行通信。在提醒服务中，我们有一个计划任务来检查提醒时间，并发布RemainderFound事件。Mailer服务中将会有一个订阅的事件，向用户发送电子邮件。
Event sourcing和 CQRS
单片应用通常具有单个关系数据库。我们可以使用ACID交易。因此，如果出现问题，我们的应用程序可以简单地开始一个事务，更改多个行，并提交事务，如果错误的话，还可以恢复到之前。不幸的是，处理微服务架构中的数据访问要复杂得多。这些数据分布在不同的数据库中，跨多个服务实施业务交易是一个很大的挑战。
在“ToDo”项目中，我们使用事件来处理跨多个服务的业务事务。 您可以查看在Mailer服务中应用的CQRS实施事件。 可以看到如何分离读和写，轻松地缩放每个部分。 我们使用关系数据库作为事件存储，然后使用Kafka分发事件。 当然我们需要将这两个动作定义为原子操作并避免存储事件，这样就不会导致JVM崩溃。 不使用Kafka作为事件存储，是因为从关系数据库构建聚合更简单。
未来的计划
您可能也注意到这个项目中尚且还有很多事情尚未解决，这是一个开发中的项目，未来我们会添加更多的东西，例如Spring云配置，Docker容器，与Jenkins的持续集成，Spring Sleuth的分布式跟踪，ELK的日志管理等。