两周实现App之项目介绍

我们将要实现的app-cloud项目是使用springcloud构建的，Spring Cloud由众多子项目组成的，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，它提供了搭建分布式系统及微服务常用的工具，如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局锁、选主、分布式会话等，满足了构建微服务所需的所有解决方案。比如使用Spring Cloud Config 可以实现统一配置中心，对配置进行统一管理；使用Spring Cloud Netflix 可以实现Netflix 组件的功能 - 服务发现（Eureka）、智能路由（Zuul）、客户端负载均衡（Ribbon）等。虽然使用当前的架构足以满足系统正常运行，但是还是存在很多问题的，比如没有统一的网关，客户端需要调用各个子系统；没有服务降级、断路器功能，一旦某个低优先级的服务挂掉了，造成整个系统都没法使用；没有一个好用的监控系统，实时预警；我们可以单独引入相关的模块来解决上面的问题，但是作为业余项目，倒不如直接使用springcloud来的爽快，一方面可以熟悉相关的组件，另一方面也可以间接的提高自己摸索解决问题的能力。

我们先来看下项目整体结构：

相应模块介绍：

看下服务注册中心配置：

当然也是支持docker的：

可以看到（红框部分，UP标识服务可用），这里我们将配置服务、网关服务、订单服务、预约服务都注册到服务中心了。

在来看下分布式配置中心配置，这里我们配置了从本地读取配置，实际生产环境可以从私服获取：

在来看下网关的配置，这里给出了简单的配置，实际上springcloud支持很多种配置方式的，如隐藏关键地址、模糊匹配等：

这样通过order访问的都会被路由到order订单子服务上去。

在来看下app-cloud-ref，是如何访问外部Rest-Api和Dubbo-Api的：

这里使用了声明式API，url的配置是从配置中心获取的，Feign可以针对每一个服务配置相应的configuration：

这里我们配置当前服务的级别为FULL（对其他服务没有影响），也就是会输出全部的日志，由于这是用Kotlin写的代码，默认都是final级别的，因此需要设置open关键词，否则的话Spring注入会失败（有兴趣的童鞋可以思考下为什么会失败）。

针对dubbo-api我们可以引入spring-boot-starter-dubbo模块（用兴趣的童鞋可以看看这个模块的源码，看看是如何注入），然后通过@Reference注解注入：

app-schedule-service是使用Kotlin实现的预约微服务，kotlin也是基于jvm的语言，它不仅可以和Java无缝互操作，还提供了其他有用的特性和语法糖，如：空值安全、字符串插值、类型推断、协程等，这部分的代码可以参考文章【两周实现APP之分院排期】，这里只给个简单的例子：

这样的话就算运算期间有个别值是null也没关系，我们可以抛异常或者给个默认值，这样我们就可以省略一大堆if-else-null的判断了。

我们这里同时使用了@HystrixCommand注解，通过它我们可以很轻易的实现服务降级等：

app-order-service是订单微服务，使用scala编写。当前的订单系统有很多不爽的地方，比如：订单状态操作很混乱，新增加一个功能往往胆战心惊，生怕加一个功能，又不知不觉引入了其他bug；以及层级很深的if-else判断；另外一个问题就是，客户端每个端都需要写一遍判断逻辑（资源浪费），当前状态可以有哪些操作？另外一个状态能有什么操作？甚至状态混乱的话，还有可能出现A客户端和B客户端对于同一个状态的判断会各自有各自的实现逻辑如果此时发现某个严重bug需要及时修复的话，AB两端因为实现逻辑不同，造成的问题就是不能统一修改....

该服务就是用来解决上面这些问题的，对于状态操作混乱，各种if-else数，该模块使用Replace Type Code with Subclasses手法进行了重构，另外提供了一个可选的AkkaFSM来管理状态变化。对于资源浪费的问题，我们可以在提供给客户端接口中返回当前可以进行哪些操作（按钮名称？按钮样式？跳转链接？），这样就不用每一个客户端都写一遍逻辑来判断当前的操作了，只需要按照相关的约定展示按钮就可以了。该模块会单独写一篇文章来详解。

rms-service是用node.js实现的微服务，没有什么重要的功能，只是用来讲解如何将非jvm微服务集成到springcloud。该功能会单独写一篇文章来讲解。

至于为什么一个项目要用java/kotlin/scala/node多个语言来实现，一方面将来可能每个服务都是由一个单独的团队来维护的，而不同团队的技术栈可能都不一样，这里只是提供了各个语言的简单实现，另一方面不同的功能使用最适合的语言来实现会更爽。

app-cloud-zipkin模块集成了Sleuth、kafka、zipkin等，用来跟踪一个请求从一个微服务到下一个微服务的传播过程，该模块主要用来分析调用链，这里先简单看下效果，后面会单独开一篇文章来详解（hystrix-turbine用来监控实现了hystrix的工程项目,后面文章也会讲到）：

最后的app-cloud-arachni模块是使用spark/arachni构建的黑盒扫描平台，用来实时扫描接口请求中可能存在的漏洞攻击，在一定程度上避免常规安全问题的发生，减少公司的损失，该模块会新写一篇文章详解。

以下是hadoop版本的离线扫描：