三、前期特殊案例讲解
Last updated
Last updated
属于学习框架的最直接方法就是看源码 ， 找到合适的项目源码 ，结合相关文档是可以整理一套东西,然后可以在实际项目中去验证和实现的。下面是我看过无数源码之后，整理的几个有价值的案例 ------ 理论上正常web项目的核心就是 RABC ，要快速迭代配合一些方法即可。
项目使用了 https://github.com/Mileworks/Mileworks-GEN ，项目中包含了RABC ，然后加上代码生成功能（从dao、services、controller、前端页面的共同逻辑），同时整合spring boot 简化了配置，形成了快速开发框架。在这个项目中也成功验证了这个架子是能适用于大部分项目中去的，后续只需要基于这个架子做变种。当然它也有自己缺陷，后面会说明。
大致的使用流程：
1.前端页面使用的是iframe , 在themeforest上爬静态页面 ，然后整合模板文件到工程中做页面的公有页面的定制化操作。
2.设计数据库，建立数据库模型。
3.生成单表的代码生成。
4.通过实际业务，同时结合现有项目，对工程进行业务切分，然后通过maven管理，把web工程切分成2块。
一个单独的web工程 ，用于封装针对Mongodb 的文件管理如下图
整个项目目录结构如下图
学习spring boot 需要其注解配置规则、大致的代码规范、特别是针对每个部分中间件的配置规则，结合之前项目经验应该很容易上手，这里推荐学习文档https://qbgbook.gitbooks.io/spring-boot-reference-guide-zh/ ，然后再阅读这套架子代码，可以对spring boot 做比较前期的上手。
~~Mileworks-GEN ~~架子的优缺点 ：
在文字广告项目中，因为前期需要花大量时间去做前端的工作调研，所以在技术选型上，我们选择了VUE + JAVA ， 但是文字编辑功能的VUE页面 最后打包是打成独立的html页面然后再植入到项目中来的，所以我们选择了折中方式，这样后台web业务逻辑用VUE的语法来写，页面的路由自己写了一套路由方式，结合代码生成器，最终照顾到了独立前端开发人员和实际的后台业务逻辑开发人员。这个项目是值得去学习的，后续对实际开发中可以借鉴使用。
在微服务中api 网关的作用是不言而喻的 ，面向微服务的架构也有其两面性。微服务并不适合所有的主体，也不能hold所有的使用场景。它适合大型应用。如果您有大型应用程序，则可以将此大型应用程序拆分成不同的模块，开发人员将能够独立地迭代，维护和构建这些模块。
微服务的每个模块（component）只做一件事情，有且仅有一件事情可以做，你可以轻松基于此迭代并且尽情的完善和创新该模块，而且还不会影响到其他的模块。每个模块之间，彼此通过接口进行通信（大多数时候），比如HTTP RESTful接口。你可以改变和实验性的搞一些实现，只要接口不改变，应用就会保持正常的运转。
面向微服务应用也有一些很典型的缺点。其中一个就是你现有有一堆不再“固定”的零部件。现在不再是单体那样一个app在一个地方做了所有事情。现在你有多个模块和（或）service。这些模块要在同一时刻共同配合才能最终呈现给用户。
在微服务的应用程序中，客户端和微服务之间的交互，有如下几个挑战：
微服务提供的 API 粒度通常与客户端的需求不同，微服务一般提供细粒度的 API，也就是说客户端需要与多个服务进行交互。
不同的客户端需要不同的数据，不同类型客户端的网络性能不同。
服务的划分可能会随时间而变化，因此需要对客户端隐藏细节。
这里我选择krakend 它担任了以下几个角色和功能：
KrakenD is an API Gateway that sits between the client and all the source servers, adding a new layer that removes all the complexity to the clients, providing them only the information that the UI needs.
KrakenD acts as an aggregator of many sources into single endpoints and allows you to group, wrap, transform and shrink responses. Additionally, it supports a myriad of middleware and plugins that allow you to extend the functionality, such as adding OAuth authorization or security layers (SSL, certificates, HTTP Strict Transport Security, Click jacking protection, HTTP Public Key Pinning, MIME-sniffing prevention, XSS protection).
KrakenD is written in Go with support for multiple platforms and is based on the KrakenD framework.
KrakenD中关键例子说明：
这个案例是官网推荐的，针对网关api 的典型例子。具体配置json 的文件方式，参考官网。
首先看docker-compose ，大致项目由四个部分组成：
例子中特别注意配置规则：
优点
缺点
前端支持浏览器适配
架子不属于前后端分离，属于传统开发模式
支持MySQL、Oracle、SQL Server、PostgreSQL数据库
不存在认证鉴权的流程，不方便终端的接入
通过数据权限，可以灵活进行数据过滤
代码生成只能针对单表去做生成逻辑
代码生成器可在线生成entity、xml、dao、service、html、js、sql代码
页面的控件生成的时候不能页面选择控件定制化
基于Session认证-选择存放redis中
不包含工作流
对应服务/镜像
对应端口
前端服务web
3000
网关krakend / devopsfaith/krakend:0.7.0
8080
后台api / jaxgeller/lwan
8000
