write by qyang
对于技术选型，一般都会由自己有什么要求、常见的技术组合有哪些、各种技术组合的优缺点比较、得出结论这几部分组成。创易的技术选型也不例外。
首先，创易是一款怎样的产品？它在技术方面都有什么要求呢？创易确切一点来讲是一款云服务产品，主要侧重于PAAS和SAAS。从PAAS方面来看，开放平台能力必须具备（即需要支持OAuth）。从SAAS方面来看，其会面向多个业务领域场景，微服务架构比较适合。服务说明、服务治理、运行健康状况监控等技术方面考量也应该是必须的。
其次，对产品形态和技术考量有了一定认知后，我们看看业界有哪些成熟的技术待选方案。 最容易想到的就是开源项目+部分自建混合，Spring security OAuth + Spring boot + swagger + spring-boot-starter-actuator + dubbo + 自己开发的配置中心等；另外就是 JHipster是一个不错的full stack解决方案 。 两者整体而言，JHipster有其优势，也有一点弊端。例如：JHipster 在领域层集成的 jdl 等uml同宗的表述方式，对一些比较复杂的表间关系很难表述；另外就是其集成的spring data的JpaRepository 内置的数据库操作方法太少，对于复杂的多表联查对应的接口暴漏稍显繁琐(另外：关于Hibernate这类ORM的弊端可以看下这篇文章的前半段http://www.infoq.com/cn/articles/Starcounter )。关于 JHipster 可以参考中文翻译 http://lming.leanote.com/post/bd1a2d1ac888
基于以上分析，最终我们采用整体基于JHipster（包括UAA Server），数据库操作基于rapid framework的代码生成工具进行扩展。
整体架构还有很多其他方面的考量。之前我们的一套架构（是一套完全基于服务治理的分布式架构），所以会依赖于很多中间件基础服务设施，但对于纷杂的创业团队来讲，前期单体架构可能更加合适，但之前我们的那一套实现其实有很多不够灵活的地方。首当其冲的就是启动时的各类初始化配置（如数据库连接信息等），所以对症的是spring cloud的config解决方案，通过在spring boot的启动类更改不同的注解和不同名称的配置文件(bootstrap.properties)就可达到切换目的，非常的不错！其次就是技术框架里集成的一些技术特性，需要有一个开关来决定是单体还是分布式处理方式（例如日志切换、分布式session、ID生成策略、缓存实现方式等）。 这就是在我们整个体系里非常重要的一个概念（Context）的具体实例（Context的ArchContext）
再说说协议层的设计，协议层即webui端或app端和服务器端提供服务的交互。现在最常用的就是http+json，我们也不例外。在这里我们要说的是请求的业务报文体和服务端服务返回的响应业务报文体。我们的设计是这样的，上行请求报文结构：
{
"style":"plain/gzip/encrypt",
"clientInfo":"{客户端相关信息}",
"data":"{请求的实际业务数据}"
}
响应报文结构：
{
"rtnCode":"返回的响应码 为空，说明是正常返回",
"msg":"错误信息",
"developMsg":"错误堆栈信息",
"uri":"错误说明url",
"ts":"服务端响应时的时间",
"style":"plain/gzip/encrypt",
"bizData":"返回的业务数据"
}
对于返回结构体，spring mvc 可以使用@ResponseBody 和 ResponseEntity两种方式，JHipster使用的ResponseEntity，它的好处是可以严格使用RESTFUL架构的http协议特性（httpstatus和httpheader），但其没法很好的对响应做横切。最终我们决定沿用以前公司的做法（@ResponseBody + ExceptionHandler）来尽量保证http协议特性（我们做了几类Exception，如BizException、SecurityBizException等， 在ExceptionHandler中对不同异常使用不同的httpstatus，如：SecurityBizException 就返回400的状态码）
