Java VS .NET：Java与.NET的特点对比单点登录（SSO）的设计

一、前言

为什么要写Java跟.NET对比？

.NET出生之后就带着Java的影子。从模仿到创新，.NET平台也越来越成熟。他们不同的支持者也经常因为孰弱孰强的问题争论不休。但是本文并不是为了一分高下。而是针对Java平台跟.NET平台做一些对比。主要围绕项目构建、Web框架、项目部署展开讨论。相信经过这些讨论可以让Java/.NET工程师对Java平台、.NET平台有更好的了解。

二、项目构建

项目构建工具

工欲善其事必先利其器。开发环境配置+工具使用当然要先讲了。

1、表面上的工具

平台	工具	ken.io的解释
.NET	Visual Studio	微软官方IDE，它具备了开发.NET应用程序的几乎所有工具
Java	Idea/Eclipse	IDE，负责管理项目以及代码的运行调试等，依赖于JDK
Java	Maven	负责管理项目模板、打包(jar包等)，依赖于JDK
Java	JDK	JRE（Java项目运行环境），Java工具（编译器等）

.NET工程师要开展工作，安装Visual Studio（后面简称：VS）就可以进行开发了。但是Java开发，只安装IDE是不行的，就算某些IDE会自动安装JDK，甚至是Maven，但是这些还是需要自己配置，不然还可能会踩坑。从开发环境的配置来说，.NET工程师操作上确实简单一些，一直下一步，等待安装完成即可。Java工程师就先要了解下工具，以及各个工具的职责。然后逐一配置。

从这个点上来说，Java的入门曲线会稍陡一些，但是Java工程师也会比.NET工程师更早关注到项目构建的重要环节。

2、实际上的工具

职责	.NET平台	Java平台	ken.io的解释
项目管理	VS	IDEA/Eclips	.NET只有微软官方IDE，Java没有官方的IDE，没有VS好用，但是有多个选择
项目模板	VS+MSBuild	IDE+Maven	.NET项目的模板是VS自带的，是直接符合MSBuild（编译器）标准的，项目由sln+csproj文件组织，Java平台编译器的标准是公开的，目前主流项目都是基于Maven模板来创建，项目由pom.xml文件组织。
编译&调试	VS+MSBuild+SDK	IDE+Maven+SDK	.NET平台的编译器是独立的，Java平台的编译器是集成在JDK中，Maven模板的项目是由pom.xml文件组织，但是编译器并不是认识pom.xml，所以编译需要Maven的参与
Package管理	NuGet	Maven	Nuget是微软官方开源的VS插件，Maven是Apache下的开源项目。ken.io觉得Maven更灵活、强大。NuGet容易上手。
打包/发布	VS+MSBuild+SDK	IDE+Maven+SDK	.NET平台的编译器是独立的，Java平台的编译器是集成在JDK中，Maven模板的项目是由pom.xml文件组织的，但是编译器并不是认识pom.xml，所以打包需要Maven的参与。IDE主要是提供图形化界面替代命令操作

从项目管理上说。VS这个IDE更好用一些，项目模板上，.NET项目模板由于有Visual Studio的存在,可以说简单易用而且丰富，Java平台的Maven模板灵活。

其实大部分差异都是编译器跟模板带来的差异。.NET平台的编译器是独立的，编译器MSBuild有一套标准，而且Visual Studio提供了丰富好用的项目模板。

Java平台的编译器的编译配置是xml文档，由于Java官方没有项目模板，IDE只负责帮你组织项目，但是并没有模板，你可以将任意目录指定为SourceRoot（代码根目录），ResourceRoot（资源文件根目录：比如配置文件）也可以任意指定，编译的时候，IDE会将你的项目代码，以及编译器所需要的编译描述/配置xml文档告诉编译器该如何编译你的项目。确实非常灵活，但是也增加了项目管理的成本。包的管理也非常麻烦，还好有Maven结束了这个混沌的Java世界。

编码特点

—	.NET	Java
类的组织	namespace：命名空间，name跟目录无关	Package：name跟目录名一致
类	.cs文件：类名跟文件名无关	.java文件，类名跟文件名无关，但一个类文件只能定义一个public类
编译产出	.dll，.exe文件	.jar，.war文件

三、框架

.NET的Web框架基本上都是微软官方的，官方的框架也最为流行，而Java平台，除了官方提供的Servlet API（相当于.NET的System.Web）其他的基本都由Spring大家族统治了。本次我们主要对比目前Web开发最常用的MVC框架以及持久层框架

功能	.NET	Java	ken.io的说明
Web核心	ASP.NET	Servlet	—
Web框架	ASP.NET MVC	Spring MVC	ASP.NET MVC是微软官方框架，Srping MVC框架隶属于Spring大家族，依赖于Spring
视图引擎	Razor	Thymeleaf/FreeMarker	Razor是微软官方的视图引擎，非常好用，Spring MVC并没有视图引擎，但是有Thymeleaf，FreeMarker。ken.io更喜欢Razor的风格
持久层	Entity Framework	MyBatis	EF是微软官方的持久层框架，易上手、开发效率高、但侵入性强。MyBatis配置灵活，无侵入性。各有利弊。

.NET平台的框架由于都是微软官方的，比较好组织，上手容易。Java平台的框架，灵活可配置。这也是Java平台一贯的风格。但是ken.io不得不吐槽的是，Spring MVC作为一个MVC框架，竟然没有自己的视图引擎，那MVC种的View去哪了？
可能是因为Java作为Web后端的主力平台，确实很少关注视图层，但是Spring MVC没有View层引擎，还是感觉不合适。Thymeleaf跟FreeMarker，ken.io更推荐FreeMarker。因为ken.io更喜欢FreeMaker的语法。可能是用惯了Razor的缘故。

四、项目部署

对于项目部署。.NET平台貌似没得选，只能选Windows+IIS，虽然有Mono，但毕竟不是支持所有的类库。而Java平台既可以选择Windows+Tomcat，也可以选择Linux+Tomcat。但是通常会选择Linux+Tomcat毕竟成本低。

职责	.NET	Java
操作系统	Windows Server	Windows Server、Linux Server
Web服务器	IIS	Tomcat（Tomcat是目前最主流的，也有其他的Servlet容易例如：JBoss）

不过Java平台的特性，Java项目的部署会比.NET项目部署偏麻烦一些。
IIS图形化界面一直下一步，再调整下应用程序池的版本就行了。而Tomcat不论是在Windows，还是在Linux，都通过修改配置文件完成站点配置。

五、后记

总结

不管是Java平台还是.NET平台都有各自的优势。平台只是一个工具，我们了解平台都是为了做出更好的选择。但不得不说，Java开源生态的发展势头迅猛，非其他平台可比，不过.NET平台也在弥补自己的短板而推出了.NET Core。期望以后不论是Java还是.NET都能欣欣向荣。

备注

.NET程序猿，如果要学习Java，可以看看ken.io写的教程

Java快速入门系列教程：https://ken.io/serie/java-quickstart

Spring Boot入门教程：https://ken.io/serie/springboot-course-basic

Java程序猿，如果想学习.NET，建议从.NET Core入手：

.NET Core快速入门教程：http://www.cnblogs.com/ken-io/p/dotnet-core-quickstart.html

如果想一起交流技术可以访问连接扫码加入QQ群：https://ken.io/home/about

本文首次发布：2017-07-31
本文原文链接：https://ken.io/note/java-vs-dotnet

本文无意引战，这个在开篇的时候也做过说明。另外，本人.NET，.NET Core，Java均在使用，没有黑任何一个平台的意图。

如果有朋友不同意本文的观点，欢迎评论交流，默默的点了反对，我也不知道您为什么反对，是吧？

本文由 ken.io 创作，采用CC BY 3.0 CN协议进行许可。可自由转载、引用、甚至修改，但需署名作者且注明出处。

一、前言

什么是SSO？

SSO英文全称Single Sign On，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。https://baike.baidu.com/item/SSO/3451380

例如访问在网易账号中心（http://reg.163.com/ ）登录之后
访问以下站点都是登录状态

网易直播 http://v.163.com
网易博客 http://blog.163.com
网易花田 http://love.163.com
网易考拉 https://www.kaola.com
网易Lofter http://www.lofter.com

本次设计目标

本篇文章也主要是为了探讨如何设计&实现一个SSO系统

以下为需要实现的核心功能：

单点登录
单点登出
支持跨域单点登录
支持跨域单点登出

二、SSO设计与实现

1、核心应用&依赖

应用/模块/对象	说明
前台站点	需要登录的站点
SSO站点-登录	提供登录的页面
SSO站点-登出	提供注销登录的入口
SSO服务-登录	提供登录服务
SSO服务-登录状态	提供登录状态校验/登录信息查询的服务
SSO服务-登出	提供用户注销登录的服务
数据库	存储用户账户信息
缓存	存储用户的登录信息，通常使用Redis

2、用户登录状态的存储&校验逻辑

常见的Web框架对于Session的实现都是生成一个SessionId存储在浏览器Cookie中。然后将Session内容存储在服务器端内存中，这个 ken.io 在之前Session工作原理中也提到过。整体也是借鉴这个思路。
用户登录成功之后，生成AuthToken交给客户端保存。如果是浏览器，就保存在Cookie中。如果是手机App就保存在App本地缓存中。本篇主要探讨基于Web站点的SSO。
用户在浏览需要登录的页面时，客户端将AuthToken提交给SSO服务校验登录状态/获取用户登录信息

对于登录信息的存储，建议采用Redis，使用Redis集群来存储登录信息，既可以保证高可用，又可以线性扩充。同时也可以让SSO服务满足负载均衡/可伸缩的需求。

对象	说明
AuthToken	直接使用UUID/GUID即可，如果有验证AuthToken合法性需求，可以将UserName+时间戳加密生成，服务端解密之后验证合法性
登录信息	通常是将UserId，UserName缓存起来

3、用户登录/登录校验

登录时序图

按照上图，用户登录后Authtoken保存在Cookie中。 domian= test. com
浏览器会将domain设置成 .test.com，
这样访问所有*.test.com的web站点，都会将Authtoken携带到服务器端。
然后通过SSO服务，完成对用户状态的校验/用户登录信息的获取

登录信息获取/登录状态校验

4、用户登出

用户登出时要做的事情很简单：

服务端清除缓存（Redis）中的登录状态
客户端清除存储的AuthToken

登出时序图

5、跨域登录、登出

前面提到过，核心思路是客户端存储AuthToken，服务器端通过Redis存储登录信息。由于客户端是将AuthToken存储在Cookie中的。所以跨域要解决的问题，就是如何解决Cookie的跨域读写问题。

解决跨域的核心思路就是：

登录完成之后通过回调的方式，将AuthToken传递给主域名之外的站点，该站点自行将AuthToken保存在当前域下的Cookie中。
登出完成之后通过回调的方式，调用非主域名站点的登出页面，完成设置Cookie中的AuthToken过期的操作。
跨域登录（主域名已登录）

跨域登录（主域名未登录）

跨域登出

三、备注

关于方案

这次设计方案更多是提供实现思路。如果涉及到APP用户登录等情况，在访问SSO服务时，增加对APP的签名验证就好了。当然，如果有无线网关，验证签名不是问题。

关于时序图

时序图中并没有包含所有场景，ken.io只列举了核心/主要场景，另外对于一些不影响理解思路的消息能省就省了。

前置知识

1、Session的工作原理和使用经验：https://ken.io/note/session-principle-skill
2、Cookie的特点和使用经验/建议总结：https://ken.io/note/cookie-feature-skill

以上，如有疑问，欢迎联系我：https://ken.io/home/about

本文首次发布：2017-11-25
本文原文链接：https://ken.io/note/sso-design-implement