微服务权限

『壹』 为什么选择Spring Boot作为微服务的入门级微框架

『贰』 Mⅰcroservice Architect是什么意思

你好同学，这个直译过来是“微服务架构师”的意思，我不是太明白这个意思的，谢谢。

『叁』 微服务总线有哪些内容

学校很多跨部门、跨业务系统的应用需求，数据格式不统一、接口标准不统一，业务流横向互通不方便。微服务总线促进业务系统横向互通，可观可控可分析，极大降低系统间耦合度，提高系统间对接的效率，为后续应用扩展提供便利。功能包括：服务协议标准化（非HTTP restful服务标准化为restful服务）、服务注册、服务发现、服务权限控制、服务日志、服务监控、服务配置管理等。

『肆』 内部微服务系统之间调用是否需要安全认证吗

想要为开发工程师们开发一个既能满足REST约束条件和原则又不像OAuth OAuth 那样复杂 the complexity ，仅仅使用简单的传值语句或者其它简单但同样安全的方法就能实现的web API? 聪明人会有聪明的想法… 问题 直接通过HTTP literally passing the credentials over HTTP以文本方式传输鉴权信息可能会被破译; 尤其在 Gawker incident, 再以文本或是弱加密的方式传输鉴权信息是非常不安全的做法 weakly-hashed anything is usually a bad idea. 即便是使用哈希加密后还是很有可能被人根据彩虹表 Rainbow Table破译出与用户名匹配的密码（个别案例） 这可该怎么办，真是郁闷… 也许你又会想到很多公共的API popular public APIs在请求中采用双数据的模式：一个公有值一个（最好是有）只有属主能访问的私有值。 ”还是有点不对!”这不跟原来（用户名密码模式）文本模式差不多么，还是可能会被（嗅探器）破译。 这时候你可能准备放弃并采用OAuth模式了，但仍坚信必有某种简单方法能实现公用webAPI安全访问私有鉴权信息。 解决方案 连续2天的Peyote实验后（你可能会找到更好的放松办法），结论终于呈现在你眼前：Amazon是拥有最大的、使用最多的在线网络API的网络服务之一，并且根本不支持OAuth！ 经过一个下午长时间的狂想之后，你最终败下阵来，并看到Amazon是如何保持API请求安全的。你不清楚为什么，但读完整页关于如何为Amazon网络服务装配一个请求后，你依然觉得不完全合理。这个“签名”和什么连在一起？代码示例中的“data”参数是什么？这样，你会继续查找关于“安全API设计”的文章。。。 当遇到其他人问同样的问题时，你看到一些指出"HMAC"或其他事物的优秀回复，但还是不太确定。 你找到其他鼓励你使用“HMAC”的文章并且你正H-FINE地使用它，如果有人将“HMAC”解释成简明的H_ENGLISH的话。 你的确偶遇了一个有道理的蒸馏的基本概念，它是这样一简明的英语描述的： 一个服务器和客户端知道一个公钥和一个私钥；只有服务器和客户端知道私钥，但每个人都知道公钥。。。但不关心别人所知道的。 一个客户端生成一个唯一的HMAC（哈希）表示它到服务器的请求。通过把请求数据（参数和值或XML/JSON或任何它计划发送的数据）以及请求数据的散列blob和私钥结合来实现。 客户端随后将这个HASH以及所有它将要发送的参数和值一并发给服务器。 服务器接到请求，并使用与客户端相同的方式重新生成自己独有的基于提交值的HMAC（哈希）。 然后，服务器比较这两个HMAC，如果相同，服务器就信任这个客户端并执行请求。 这似乎很直截了当。最初让你困惑的是，你以为原始请求是经过加密传送的，但实际上，HMAC方法所做的一切只是使用只有客户端和服务器才知道的私钥将参数生成为一些独特的校验和（哈希）。 随后，客户端将这个校验和及原始参数和值发给服务器，然后服务器复核校验和（哈希）以确定它接受客户端所发的请求。 因为根据假设，只有在客户端和服务器知道私钥，我们假设如果他们的哈希匹配，那么它们会互相信任，以至服务器随即正常处理这个请求。 你知道在现实中，这就相当于某人过来对你说：“Jimmy让我告诉你把钱给Johnny”，但你不知道这个人是谁，所以你要伸出手去试探他，看看他是否知道这个秘密握手。 如果三次握手证明无误，则通讯继续进行，否则中断通讯。. 你明白了大概是怎么回事，但还是想会不会还有更好的方法呢？还好，有tarsnap网站 tarsnap帮你答疑解惑。看看亚马逊是如何解决签名认证问题的Amazon screwed this up with Signature Version 1. 看完了亚马逊的web service是如何鉴权的，re-read how Amazon Web Services does authentication 讲的确实有道理，整个流程如下: [客户端]在调用REST API之前，首先将待发送消息体打包, combine a bunch of unique data together(websevice端将要接收的数据) [客户端]用系统分派的密钥使用哈希(最好是HMAC-SHA1 or SHA256 ) 加密(第一步的数据). [客户端]向服务器发送数据: 用户身份认证信息例如,用户ID，客户ID或是其他能别用户身份的信息。这是公共API，大家都能访问的到(自然也包括了那些居心叵测的访问者)系统仅仅需要这部分信息来区分发信人而不考虑可靠与否(当然可以通过HMAC来判断可靠性). 发送生成的HMAC码. 发送消息体（属性名和属性值），如果是私有信息需要加密，像是（“mode=start&number=4&order=desc”或其他不重要的信息）直接发送即可. (可选项)避免重放攻击 “replay attacks” o的唯一办法就是加上时间戳。在使用HMAC算法时加入时间戳，这样系统就能依据一定的条件去验证是否有重放的请求并拒绝. [服务器端]接收客户端发来的消息. [服务器端] (参看可选项)检查接收时间和发送时间的间隔是否在允许范围内（5-15分）以避免重放攻击replay attacks. 提示: 确保待检对象的时区无误daylight savings time 更新: 最近得到的结论就是直接使用UTC时区而无需考虑DST的问题 use UTC time . [服务器端]使用发送请求中用户信息（比如.API值）从数据库检索出对应的私匙. [服务器端] 跟客户端相同，先将消息体打包然后用刚得到的私匙加密（生成HMAC）消息体. (参看可选项) 如果你使用了加入时间戳的方式避免重放攻击，请确保服务端生成的加密信息中拥有和客户端相同的时间戳信息以避免中间人攻击man-in-the-middle attack. [服务器端] 就像在客户端一样，使用HMAC哈希加密刚才的信息体. [服务器端] 将服务器端刚生成的哈希与客户端的对比。如果一致，则通讯继续；否则，拒绝请求! 提示: 在打包消息体的时候一定要考虑清楚，如果像亚马逊进行签名版本1中信息识别那样会面临哈希冲突的问题 open yourself up to hash-collisions! (建议：将整个包含URL的请求加密即可!) 特别提示:私匙绝对不能在通讯过程中传递，它仅仅用来生成HMAC,服务器端会自动查询出它的私匙并重新生成自己的HMAC.我来翻译公匙仅仅用来区分不同的用户，即使被破解也无所谓。因为此时的消息无需判断其可靠性，服务端和客户端还是要通过私匙来加密（比如，前缀、后缀，倍数等等） 10/13/11更新：Chris最近发现 pointed out 如果在HMAC计算中加入了URI或是HTTP请求/回复，攻击者更易通过更改末端或是HTTP方法来搞破坏。比如，在HTTP POST方法中将/issue/create改成/user/delete。

『伍』 与单块架构相比较，微服务架构有哪些特点

这就是三十年河东、三十年河西的轮流转。
当年提出系统结构要内聚，接口要简洁清晰；如今的微服务正好相反。
所谓微服务就是这个系统的每个模块都是自成一体的，可以认为其拥有不依赖其他模块的能力。这样一来，其可以独立向外提供服务，甚至可以独立存在。
我举个例子，你就懂了：一个网站，又有登录、又有新闻、又有BBS、又有邮箱，按说这是一个整体，无论登录权限，还是浏览、交互都是机体的一部分。不能割裂。但在微服务体系下，这些都是独立的，你可以理解为新闻是一个独立的割裂存在，BBS是一个独立的割裂存在，邮件是一个独立的割裂存在。你懂了吗？无论是界面、还是业务逻辑、还是数据存取都是各自的独立一套。不是仅界面割裂，是完全的从上到下的割裂。我觉得例子功能粒度大，也可以功能粒度更小。
你可以想想，每个模块都可以独立存在，对外提供功能。甚至其他模块不存在，某模块也可以独立存在，这不是小系统是什么？而每个这种模块堆起来一个所谓的系统。那这中间为了保障每个模块独立存在的那些功能又得重复多少啊！？你想想吧，每个模块都有一套维持其存在的这种机制，每个模块都有这么一堆。这不是重复实现吗？这还哪有一个系统的概念哪！？简直就是功能超市。所以，这怎么说呢？反正就是这么个玩意儿吧！

『陆』 传智播客Java的课程中大概包含哪些技术

①实战为主+前沿技术：整体课程中项目部分课程占到60天，项目中引入时下流行元素，如前后端分离式开发、微服务、容器化部署、DevOps、智能推荐、智能分类等,配以随堂测试、阶段测试、每日作业等教辅工具，让学生能真正消化与理解所学知识点，并学以致用，真正掌握面向企业的开发方法。
②解决方案式教学：项目中阶段引入多达40+的解决方案，如分布式架构、集群部署、微服务、海量数据存储、分布式日志、云存储、大数据存储、权限管理、在线支付等，让学员真正面对企业中实际问题，成为符合当前企业要求的软件开发精英。

『柒』 力软敏捷开发框架怎么样啊，用起来如何

力软的开发框架用起来也不错，简单，是.NET语言，适合做一些生产和OA 协助的；
目前主流的还是JAVA；并且在部署上也上升一个台阶。从单机部署，到双击部署，集群部署，微服务部署，容器部署等多元化的支撑和适配，不只是口头说过的支持就好，myapps的微服务在杭州的项目中，直接落地K8S和容器部署，doc部署多种方式，来协助企业做好规划和颗粒度的成长，。目前需要做好调整和配置的思路整体规划，适配未来的缓存机制和队列部署以及负载均衡的机制，才可以通过中间件直接实现相关的效果；
所以未来的发展趋势也是主要考评标准，力软的客户群体还是挺稳定，产品线在北方的销量还是持续上升的。只是不知道部署上是否支持微服务和容器部署，这个找机会体验下产品，交流下他们的部署方式才好有更加优质优良的推荐
管理顾问，每天成长一点点，努力成就自己的优秀。

『捌』 Java开发需要哪些技术

作为一个Java开发人员，最百大的挑战就是不断更新了解新的技术。在时代的变化中，主流技术的掌握也是一门持久的功课。
1、微服务技术
微服务架构主要有：Spring Cloud、 Dubbo、 Dubbox等，以 Dubbo占比最高，可度达26%，微服务网关技术，使用问springcloud-zuul的程序员占比最高。
2、远程调用技术答
使用RPC框架的程序员中， 使用Dubbo的人数占前端要学好必须每天坚持学习。为了方便大家的交流学习，也是创建了一个群每天都有分享学习方法和专业老师直播前端课程，这个扣裙首先是132 中间是667 最后是127 前端学习零基础想要学习的同学欢迎加入，如果只是凑热闹就不要来了!!!比最高，其次为 bbox、gRPC、hessian也具有一定的使用比例。内
3、开发技术
多数程序员在工作中使用的开发技术为权限管理和消息队列。1/4的程序员在工作中使用的开发技术为报表技术、分布式缓存技术和负载均衡解决方案。
4、权限管理技术
shiro的使用比例最高，其次为spring security和自定义框架。
5、消息队列技术
消息队列技术主要有：ActiveMQ、RabbitMQ和Kafka。RocketMQ的使用人数较少容。

『玖』 微服务开发中的数据架构应该怎样设计

前言

微服务是当前非常流行的技术框架，通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性，可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。为业务创新和业务持续提供了一个良好的基础平台。本文分享在这种技术架构下的数据架构的设计思想以及设计要点，本文包括下面若干内容。

• 微服务技术框架中的多层数据架构设计

• 数据架构设计中的要点
  

• 要点1：数据易用性

• 要点2：主、副数据及数据解耦

• 要点3：分库分表

• 要点4：多源数据适配

• 要点5：多源数据缓存

• 要点6：数据集市

为了容易理解，本文用一个简化的销售模型来阐述，如下图。图1显示了客户、卖家、商品、定价、订单的关系（这里省略支付、物流等其他元素）。

图1 销售模型

在这个销售模型中，卖家提供商品、制定价格，客户选择产品购买、形成销售订单。根据微服务的理念设计，可以划分为客户服务、卖家服务、商品服务、定价服务、订单服务，以及公共服务（比如认证、权限、通知等），如图2所示。



图9 数据缓存

要点6：数据集市

数据集市是一个很大的话题。当现有的数据不能简单地通过几个表数据关联以及简单加工后就可以供业务使用的时候，就需要考虑构建数据集市。数据集市以数据运用的观点来分析加工数据，通过多源数据的导入、清洗、加工、视图做成等一系列的数据操作后，为业务提供可用的、稳定的数据源。例如，对销售分析中、什么样的客户喜欢什么样的商品、价格对销售金额的影响、销售金额跟地区日期的关联关系等多维度分析，就要用数据集市的概念，如图10所示。

图10 数据集市

数据承载着信息，好的数据架构设计会使业务系统变得更加流畅、更加容易理解和维护。本文只是总结一些在实际工程中的体会，供大家分享。如果有不足之处、也请大家补充、赐教。

（此文转载至GitChat技术杂谈）