Mobabel

Just One Pure ITer

Category: Micro Service Architecture

[转]如何设计权限管理模块 0

Authorization

[转]如何设计权限管理模块

我们比较常见的就是基于角色的访问控制，用户通过角色与权限进行关联。简单地说，一个用户拥有多个角色，一个角色拥有多个权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间、角色与权限之间，通常都是多对多的关系。如下图：

[转]如何在微服务架构中实现安全性？ 0

Authorization

[转]如何在微服务架构中实现安全性？

网络安全已成为每个企业都面临的关键问题。几乎每天都有关于黑客如何窃取公司数据的头条新闻。为了开发安全的软件并远离头条新闻，企业需要解决各种安全问题，包括硬件的物理安全性、传输和静态数据加密、身份验证、访问授权以及修补软件漏洞的策略，等等。无论你使用的是单体还是微服务架构，大多数问题都是相同的。本文重点介绍微服务架构如何影响应用程序级别的安全性。

[汇总]Spring Security和OAuth2 0

Authorization

[汇总]Spring Security和OAuth2

Spring boot使用Spring Security和OAuth2保护REST接口 Spring Security 最佳实践 Spring Security简介 Spring Security 认证流程 Spring Security 项目搭建 导入依赖 访问页面 自定义用户名和密码 UserDetailsService详解 PasswordEncoder密码解析器详解 登录配置 角色权限 403 权限不足页面处理 RememberMe（记住我） Spring Security 注解 Spring Security中CSRF 什么是CSRF?    

[转]有赞百亿级日志系统是怎么设计出来的? 0

Log Aggregation

[转]有赞百亿级日志系统是怎么设计出来的?

日志平台为集团所有业务系统提供日志采集、消费、分析、存储、索引和查询的一站式日志服务。 主要为了解决日志分散不方便查看、日志搜索操作复杂且效率低、业务异常无法及时发现等等问题。 随着有赞业务的发展与增长，每天都会产生百亿级别的日志量（据统计，平均每秒产生 50 万条日志，峰值每秒可达 80 万条）。日志平台也随着业务的不断发展经历了多次改变和升级。 本文跟大家分享有赞在当前日志系统的建设、演进以及优化的经历，这里先抛砖引玉，欢迎大家一起交流讨论。

[转]从单个服务器扩展到百万用户的系统 0

SOA Architect to MS Architect

[转]从单个服务器扩展到百万用户的系统

你开发了一个网站（例如网上商店、社交网站或者其他任何东西），之后你把它发布到了网上，网站运行良好，每天有几百的访问量，能快速地相响应用户的请求。 但是有一天，不知道什么原因，你的网站出名了！ 每分每秒都有成千上万的用户蜂拥而至，你的网站变得越来越慢…… 对你来讲，这是个好消息，但是对你的Web应用来说这是个坏消息。因为现在它需要扩展了，你的应用需要为全球用户提供7*24不宕机服务。

[汇总]日志开发经验 0

Log Aggregation

[汇总]日志开发经验

Spring Boot 服务监控，健康检查，线程信息，JVM堆信息，指标收集，运行情况监控等！ Spring Boot是如何实现日志的？ 阿里巴巴不允许工程师直接使用Log4j和Logback的API！ 3种常见的数据脱敏方案 一个注解搞定接口返回数据脱敏

[汇总]微服务构架经验 0

MS Design Princinple

[汇总]微服务构架经验

1. 最佳实践 微服务架构，多“微”才合适？ 微服务到底该多大？如何设计微服务的粒度？ 如何更好地干掉微服务架构复杂性？ 我大概总结了三个关键词，分别是引入、异构、冗余。 B站在微服务治理中的探索与实践 7个阶段模型，帮助微服务架构落地！ 这里提供了三种策略给大家参考，如图所示： 第一种 Cream Scoop Strategy 冰淇淋勺策略：是 Martin Flower 提出的一种策略，也被称为扼杀者方法。可以想象有一大桶冰淇淋，这桶冰淇淋就代表现有的架构，可以用勺子从桶中挖出你们想要的冰淇淋，这个挖出的部分就是要做拆分的服务。最终可以将大桶冰淇淋挖出一个个独立的服务，这里服务包含不同的业务逻辑。这种方式是逐渐修改原有系统，并且逐步对服务进行拆分试错然后过度到单独的资源上运行。每次拆分对系统的影响较小，但是整个系统的拆分和重构需要较长时间。 第二种 乐高法策略（搭积木），把原有的系统想象成一大块乐高积木，我们只需要往上面添加小的乐高积木模块就行了，添加的小模块就是一个个微服务。这样一来就不用对老产品进行调整，新的功能通过微服务的方式实现并且集成到老的产品中。不过需要通过一种能够让微服务与老产品联系的方法，这里会使用到接口编程以及适配器模式。 第三种是 nuclear 策略，和策略的名字一样我们需要对老旧系统推到重来，重新打造微服务架构，说起来容易这里需要花费大量分析和重构的时间，这个周期比较长，成本也是较高的。