微服务

一文了解微服务架构的分解设计

东方证券：我们如何成功实施微服务

3 个注解，优雅的实现微服务鉴权

随着互联网行业的发展，对服务的要求也越来越高，服务架构也从单体架构逐渐演变为现在流行的微服务架构。这些架构之间有怎样的差别呢？

开发团队越来越多地选择微服务架构而不是单体结构，以提高应用程序的敏捷性、可扩展性和可维护性。随着决定切换到模块化软件架构——其中每个服务都是一个独立的单元，具有自己的逻辑和数据库，通过 API 与其他单元通信——需要新的测试策略和新的测试工具。

程序员，立之根本还是技术，一个程序员的好坏，虽然不能完全用技术强弱来判断，但是技术水平一定是基础，技术差的程序员只能CRUD，技术不深的程序员也成不了架构师。程序员对于技术的掌握，除了从了解-熟悉-熟练-精通的过程以外，还应该从基础出发，到进阶，到源码，到实战。所以，程序员想要成功，首先要成就自己。

如何构建基于 DDD 领域驱动的微服务？

最近刚好有小伙伴在微信上问到这个问题，松哥就来和大家聊一聊，本文主要和小伙伴们聊一聊思路，不写代码，小伙伴们可以结合松哥之前的文章，应该能够自己写出来本文的代码。当然，思路也只是我自己的一点实践经验，不一定是最完美的方案，欢迎小伙伴们在留言中一起探讨。

微服务架构 目前微服务是非常火的架构或者说概念，也是在构建大型互联网项目时采用的架构方式。随着业务需求的快速发展变化，需求不断增长，迫切需要一种更加快速高效的软件交付方式。而微服务可以弥补单体应用不足，是一种更加快速高效的软件架构风格。

开发者对于生产问题故障的排查、定位，随着微服务的喷发，也不再像是以前那边依赖纯日志、gc日志进行问题排查与定位了，本节开始介绍一个生产环境使用的排错工具Arthas，帮助大家更高效、便捷地实现生产问题排错。

应用的硬件、软件架构在涉及到部署时，一般会根据实际请求量做一定的压力测试，以测试系统稳定性、健壮性，避免后续线上未知故障。假设在一个电商的秒杀场景下，订单中心本身能够承载的QPS预设是10W，因为活动的火爆导致流量瞬时达到100W，此时订单中心因无法承载其10倍的请求将会崩溃，那么对于整个分布式架构系统会产生什么问题呢？本节我们将借助于Sentinel的流量控制、隔离降级来解决上述分布式架构中常见的雪崩问题。

在分布式架构系统中，服务不止一个，一个完整的业务链路肯定也不止调用一个服务，此时每个服务都有自己的数据库增删改查，而每一个写操作对应一个本地事务。如果想要确保全部的业务状态一致，也就意味着需要所有的本地事务状态一致，这在我们之前的学习中肯定是不具备的，如何做到跨服务、跨数据源的事务一致性将是本章节的重点学习内容。

在RabbitMQ的官方文档中，讲述了两种集群的配置方式： ● 普通模式：普通模式集群不进行数据同步，每个MQ都有自己的队列、数据信息（其它元数据信息如交换机等会同步）。例如我们有2个MQ：mq1，和mq2，如果你的消息在mq1，而你连接到了mq2，那么mq2会去mq1拉取消息，然后返回给你。如果mq1宕机，消息就会丢失。 ● 镜像模式：与普通模式不同，队列会在各个mq的镜像节点之间同步，因此你连接到任何一个镜像节点，均可获取到消息。而且如果一个节点宕机，并不会导致数据丢失。不过，这种方式增加了数据同步的带宽消耗。

CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。 整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。

Axon Framework是一个适用于Java的、基于事件驱动的轻量级CQRS框架，既支持直接持久化Aggregate状态，也支持采用EventSourcing。

本文介绍了微服务基本概念、演变过程，主要的原则及优缺点，最后谈到了微服务的实现方案之一，作为引文此章节偏理论知识一些。后续笔者将借助具体技术实现带领读者一起逐步实现微服务架构体系。

Casbin（<https://github.com/casbin/casbin>）是一套访问控制开源库，致力于帮助复杂系统解决权限管理的难题。同时也是一个国产开源项目。Casbin采用了元模型的设计思想，既支持ACL（访问控制列表），RBAC（基于角色访问控制），ABAC（基于属性访问控制）等经典的访问控制模型，也支持用户按照自身需求灵活定义权限。Casbin已经被Intel、IBM、腾讯云、VMware、RedHat、T-Mobile等公司开源使用，被Cisco、Verizon等公司闭源使用。具体详见Casbin主页（<https://casbin.org/>）。