前提
现有商城开发重构
框架选择范围
1. 使用开源框架自定义开发
- PYTHON 语言的OSCAR商城框架
- GO语言的QOR商城框架
- JAVA语言的OFBIZ商城框架
2. 微服务框架重构现有商城
- playframework
- spring cloud
-
Apache ofbiz
框架简介
优势
从架构图中可以看到ofbiz的所有app都构建在framework之上。framework的核心就是ServiceEngine（服务引擎）、EntityEngine（实体引擎）。实体引擎对于数据库的种类支持都非常健全。
权限方面，ofbiz采用的是角色+安全组的授权模型。
OFBiz几乎实现了所有的J2EE核心设计模式，各个模块之间的耦合比较松散，用户能够比较容易的根据自己的需要进行拆卸，非常灵活。
劣势
根据官方文档指导，在本地部署运行了ofbiz。
查阅了相关文档，默认支持soap的webservice服务，没有开放的restful api文档。
-
QOR - Golang
优势
QOR是首个使用Go语言开发的电商系统、CMS的SDK。它是一组用Go编写的库，用于抽象业务应用程序，内容管理系统（CMS）和电子商务系统（EC）所需的通用功能。
Go语言本身具有的特点是：速度快、高性能、灵活、开发快速、安全等，这些都是得到开发者的广泛认可的。QOR使用Go语言开发，能够将该语言的各方面优势也应用到产品中去。
Admin模块可以快速生成一个漂亮、可跨平台运行、可配置的管理后台。
Publish模块设置了预演和正式两种服务器环境，可以在正式发布之前预览此次更新的内容。
Internationalization(i18n)国际化翻译工具。
Localization(l10n)本地化智能管理业务对象。
Transition模块能够体现业务流程和执行业务规则。
MediaLibrary模块支持上传文件至云端，支持图像自定义处理。
劣势
技术团队对Go语言无经验，会导致自定义开发过程中风险不可控。
-
django-Oscar
暂无
-
playframework
框架简介
Play Framwork是一个轻快的REST风格的框架。
Play 1.x 使用Java开发，只支持Java项目，只维护不更新。
Play 2.x 使用Scala和Java开发，同时支持Java和Scala项目。
优势
热部署
Play 框架自动编译 Java 源代码，然后直接热加载到 JVM 中而不需要重启服务器。编辑代码后，框架自动重新加载，然后直接就看到修改后的结果。
Play2的模板引擎
简单易上手, 没有JSP里面繁杂的内置对象和指令, 全部功能都通过方法调用完毕。 支持反向路由。
极少量的配置
绑定一个 URI 模式到 Java 调用只需要在route中定义一行代码。
JPA 持久化
Java 持久化接口( Java Persistence API )是一个简洁的 Java 版的 ORM 框架，不需要任何配置，Play 会自动启动 JPA 实体管理器，并在代码发生修改时自动地同步。
全栈的应用框架
- 支持 JDBC 的关系数据库
- 基于 Hibernate ( JPA 接口 ) 的对象-关系映射框架( ORM )
- 集成的缓存支持，易用的分布式缓存系统( memcached )
- 简单直接的提供 JSON 和 XML 的 Web Service 服务(不是 SOAP)
- 支持使用 OpenID 进行分布式的身份认证
- 可以将 Web 应用部署到任何地方(应用服务器，GAE ，云服务，等等)
- 图像处理 API
劣势
我之前使用过Play 1.x，虽然支持JPA 持久化，但是不支持方言。
Play2.x是否有优化还需要再查阅资料。
不支持方言就会导致对数据库的操作很不灵活。
-
spring cloud
Spring Cloud 是一套完整的微服务解决方案，基于 Spring Boot 框架。
优势
完整的微服务解决方案。
约定优于配置，基于注解，没有配置文件。
轻量级组件，Spring Cloud 整合的组件大多比较轻量级。
开发简便，Spring Cloud 对各个组件进行了大量的封装，从而简化了开发。
开发灵活，Spring Cloud 的组件都是解耦的，开发人员可以灵活按需选择组件。
劣势
项目结构复杂，每一个组件或者每一个服务都需要创建一个项目。
部署门槛高，项目部署需要配合 Docker 等容器技术进行集群部署。
初步调研结论
由于时间有限，Oscar和spring cloud、boot没有写完整。
但是根据这些天的初步调研，更倾向于使用微服务框架重构现有商城。
play轻且灵活，spring cloud更重一点。
