使用 Spring Social 连接社交网络

显示全部楼层 · 2007-1-24 12:56:49

清单 4. SignInUtils 类的 signIn 方法的实现
点击查看代码清单
前端页面
只需要通过页面向登录控制器的 URL 发出一个 POST 请求，就可以启动通过 LinkedIn 进行登录的过程。如代码清单 5 中，通过表单提交就可以启动登录过程。用户会被首先转到 LinkedIn 网站的授权页面给应用授权，授权完成之后就可以进行注册。
清单 5. 登录页面
Or Connect by

LinkedIn
默认情况下，当第三方网站授权完成之后，用户会被转到 URL“/signup”对应的页面。在这个页面，用户可以补充一些相关的注册信息。与此同时，从第三方网站获取的用户概要信息，如用户的姓名等，可以被预先填充好。该页面在表单提交之后的操作，由代码清单 6 所示的控制器来处理。
清单 6. 用户注册控制器的实现
点击查看代码清单
当用户提交注册表单之后，根据用户填写的信息创建相应的账号，然后登录新注册的账号并跳转回首页。

千问 · 2007-1-24 12:56:49

结束语
在社交网络日益流行的今天，Web 应用都应该考虑增加对社交网络的支持。这样既方便了用户，让他们省去了重新注册的麻烦，又可以增加用户粘性，同时可以通过社交网络进行推广。虽然很多社交网站都提供了开放 API 来让应用使用其服务，但是集成所需的工作量是不小的。Spring Social 作为 Spring 框架中的一部分，为在 Web 应用中集成社交网络提供了良好支持。本文详细介绍了如何通过 Spring Social 来实现通过社交网络账号进行登录以及使用社交网络提供的 API。

千问 · 2007-1-24 12:56:49

基于特定场景的Docker效能评测与分析
微软开放技术一直以来积极参与容器技术，不但在微软的公有云平台实现了对Docker的支持，而且我们内部的很多项目也开始积极采用或者迁移到Docker环境中。其中有一个项目，早期是利用原有的虚拟化技术，在云平台上通过部署与启动大量虚拟机，来达到对多用户同时在线提供弹性的云服务。由于项目的设计和要求，需要做到用户的环境隔离，所以基本上一个用户需要有一个对应的虚拟机。当服务需求达到高峰时，需要部署和启动大量的Linux虚拟机。这带来了显著的资源开销，并且在云环境下最终转换为等价的成本开销。由于虚拟机的启动是由需求动态驱动的，对终端用户来说启动时间也造成了用户体验的下降。
针对这一问题，我们在第一时间就开始尝试Docker基础上的容器技术。但是针对我们的特定应用场景，需要评估一下效能，以及功能上是否达到甚至好于原有虚拟机架构基础上一样的要求。功能和效能的测试思路描述如下：
功能测试。我们采取将原有的多个虚拟机的集群部署，改为在少量的虚拟机上的Docker容器集群，即原来的一个虚拟机上的所有的代码和库，都转制生成完全对应的Docker容器，基本上一对一。例如原来是8个不同角色和任务的虚拟机节点组成的集群，转化为8个不同角色和任务的Docker容器。端口映射到宿主虚拟机的不同端口，进而通过云服务面向互联网公共端口。整个容器基础上的集群启动运行后，经测试，功能上和原有的虚拟机集群没有任何区别。
效能测试。我们并不做性能测试（benchmark），因为我们相对于极值，更关心在模拟实际应用部署场景时的次序，资源的利用效率和容量。因为实际场景中，每一个新的节点的生成需求并不是同步和同时的，所以我们的模拟生成频率是每隔数秒启动一个预制的容器，每个容器映像预装了一个最简单的python脚本，启动运行后，持续的循环做很简单的基本运算，使得单个容器的CPU平均使用量大致与我们实际应用时实测的真实应用的CPU使用量相当，在0.1%-0.9%之间。
测试环境：
宿主的虚拟机配置：1 core， 2GB RAM， 20GB HD，入门级的低端配置。
Docker映像尺寸：500MB， Ubuntu 14.04，with ssh, ruby, python and a simple application
对应的虚拟机映像尺寸：5GB （对应Docker和VM尺寸大概有一个数量级差别）
当Docker映像下载到本地后，启动一个容器耗时不到1秒，和云端虚拟机的启动动辄1-2分钟甚至更久基本上不在一个数量级。
容器启动后，无延迟，立即可以使用。
首先监测随启动的容器总量增加，可用内存的递减规律。结果如下图（y轴单位kB，x轴容器实例数），在200个容器以内，内存耗费基本呈线性。并且Docker并未将映像的所有内容都加载到内存。

再监测单个容器平均占总内存百分比随容器增加的变化。如下图（y轴单位%，x轴容器实例数），前20个容器平均内存开销虽然较小，但是波动较大，之后是相对均匀区域，有小量增长，但是波动被平均化了。当继续增加到约150时，平均花费和波动都开始增加，显示额外开销（overhead）加大，波动也增大到无法被平均值平滑了。具体的研究也与此一致，从150个容器开始，开始出现不可用，无反应或者无法杀掉的僵尸容器（Zombie）。升至200时我们平均录得6个僵尸容器。所以在我们这个特定的配置，场景和环境下，可以认为150是个资源分配上的有效极值。

在从零到200个容器实例的部署启动过程中我们监控了此一过程中的CPU使用情况。由于我们的容器尚未附加大量工作负载，所以这个数据反应的的是基准CPU开销（baseline）。结果如下图，由宿主环境录得的数据显示（y轴单位%，x轴为容器实例数），在单一宿主环境下启动容器的CPU开销很小，200个容器时也基本在5-6%以下。而且在此区间内随部署容器的增加，CPU花费基本呈线性。

由于时间所限，我们暂时还没有对网络带宽花费做测试，这将在后续的工作中逐步完成。但是基于经验估算，假设一台宿主机的带宽为1000M bps，当被大量共享时实际可用带宽不到70%，再折算为Bps，并考虑HTTP的额外开销之后，实际可用带宽约60MBps，分到200个同样的容器，每个容器的现实带宽大概只有300K Bps。这对一般的网站或网络应用是基本够用，但是高峰和一些消耗带宽的应用就需要认真测算。

千问 · 2007-1-24 12:56:49

结果讨论
综上所述，在云计算环境用户主要关注的资源——CPU、内存、存储、网络带宽四大要素中，在一定范围内，增加同质容器实例的数目时，资源的耗费基本为线性。所以如果要做优化的资源调配，需要进行单个应用的平均和峰值评测，结合负载的模式（pattern），来计算最有可能先达到瓶颈的资源，并以此为上限优化资源调配算法。由于异源容器应用实例的不确定性，最有效的部署方式是同源的容器应用实例，尽量部署到同样的宿主环境，因为这样可以相对精确的取得单个容器实例的平均资源花费，从而作为经验参数代入资源配置的算法里，得到优化的结果。
此外在架构层面，由于对资源使用效率要做精细化分配，不同角色的模块，扩展曲线会有很大不同，所以建议松散耦合，按角色、堆栈层分离模块，分别做标准的分布式部署，以达到最大效能。比如标准MVC网站架构，可以将所有模块打包到一个容器映像，部署和扩容时会很简单。但是如果要最大化资源利用效率，应当数据层，应用层和网络服务器层分开建立容器映像，分开部署，独立扩容。当然这就需要更有效的工具和框架的帮助来实现。

千问 · 2007-1-24 12:56:49

总结
我们在微软公有云环境下的对Docker现实场景的应用实践，使我们得到了从用户角度出发，在类似场景下应用时可能遇到的问题及第一手资料。经过对某些特定场景下的资源利用效率评测，也更好的了解了以Docker为代表的容器化技术的适应对象和需要关注的问题。微软开放技术会一如既往的持续加大对容器技术的研发和投入。并希望和国内的开源社区一起推动容器技术的应用，使这项可以为用户节省大量资源的技术能在更多的产品环境中和应用场景中真真正正得到广泛而持久的应用。
进深阅读
携手 Google 和 Docker 为 Microsoft Azure 带来全新的开源容器技术
Docker与微软展开战略合作，实现基于Container的跨平台应用开发
Create a Docker Host on Microsoft Azure
Understanding Docker Containers on Microsoft Azure with Kubernetes Visualizer
Getting Started with Docker on Microsoft Azure
作者介绍
商之狄，现任微软开放技术（中国）首席项目经理，从事开源技术、云计算和大数据相关的新技术研发与推广工作。商之狄曾在美国硅谷的start-up、互联网及电子商务领域工作多年：曾参与过用超级计算机进行最早的人类基因组全注释；用机器学习、并行计算和计算机视觉技术帮助全球最大的制药公司从数百万潜在药物中快速筛选抗癌新药；参与开发过语义基础上的垂直搜索引擎；在全球最大的支付企业技术研发部进行超高通量交易和欺诈检测业务向大规模云环境迁移的试验。在全球最大零售企业的电子商务部门任资深架构师时，领导开发了大数据基础上的全自动精准在线推广营销系统。