分类： 技术

SOA应该是一个可递归的概念。
在不同的层级下具有相同的架构，即一组功能对外形成契约，然后组成一个服务
多个服务组成并表达出了企业的战略目的.

新技术真的好么，我并不觉得，至少我所在的层级很不喜欢各种新技术
我原来从来没用过MyBatis，总听说多好多好，但是在绝大部分场景下，都不如我直接用spring jdbc template来的方便，它那套orm转换预设了太多假设，为了解决那一堆不符合假设的场景又发明一堆概念。

比方说一个很简单的例子：

• 我的数据库的时间字段是varchar类型保存的，那么我用Spring jdbc大概会需要对一个表对象写大约二十行的代码做orm转换。
• 但是我用Mybatis也不见得少几行，特别是用xml写sql的时候还要自己指定Handler来做转换。
• 有一点更不方便，项目大部分都采用spring做对象管理，当基础包和上层应用都用spring管理了，而基础包却依赖了某个特定的spring配置项，然后大家就呵呵了

其实最中心想吐槽的应该是，基础包应该尽可能的少依赖外部，或者说自有配置应该打包输出并封装在自己的项目，不要和上层应用发生耦合，会造成各种的不舒服.

网络传输的数据结构要点：

要能区分出数据来源

要能区分数据新旧

要能分辨数据正确性

除了对数据结构的直接操作，其他都应该是外部组件

数据状态

正常

过旧

冲突（定义为异常状态需要使用者自己处理）

以上抽象成Condition

可能的复杂点

多数据冲突同一个数据，组件不解决，应该由业务处理

组件需要保证每次同步都将会是原子操作，故而多线程并发会是难点

尽可能使的组件易于扩展（尽量用接口编程）

无idea情况下

建立一个目录，shell进入相应的目录，执行gradle init就能够创建一个java项目了

gradle采用约定大于配置的模式，类似maven，以下是一个gradle项目目录结构：

├─.gradle
│  ├─3.3
│  │  └─taskArtifacts
│  ├─3.5
│  │  ├─file-changes
│  │  ├─fileContent
│  │  └─taskHistory
│  └─buildOutputCleanup
├─.idea
│  ├─libraries
│  └─modules
│      ├─module1
│      └─module2
├─build
│  ├─libs
│  └─tmp
│      └─jar
├─gradle
│  └─wrapper
├─module1
│  ├─build
│  │  ├─classes
│  │  │  ├─main
│  │  │  │  └─com
│  │  │  │      └─michaelssss
│  │  │  └─test
│  │  │      └─com
│  │  │          └─michaelssss
│  │  ├─libs
│  │  ├─reports
│  │  │  └─tests
│  │  │      └─test
│  │  │          ├─classes
│  │  │          ├─css
│  │  │          ├─js
│  │  │          └─packages
│  │  ├─test-results
│  │  │  └─test
│  │  │      └─binary
│  │  └─tmp
│  │      ├─compileJava
│  │      ├─compileTestJava
│  │      │  └─emptySourcePathRef
│  │      └─jar
│  └─src
│      ├─main
│      │  └─java
│      │      └─com
│      │          └─michaelssss
│      └─test
│          └─java
│              └─com
│                  └─michaelssss
└─module2
    ├─build
    │  ├─classes
    │  │  ├─main
    │  │  │  └─com
    │  │  │      └─michaelssss
    │  │  └─test
    │  │      └─com
    │  │          └─michaelssss
    │  ├─libs
    │  ├─reports
    │  │  └─tests
    │  │      └─test
    │  │          ├─classes
    │  │          ├─css
    │  │          ├─js
    │  │          └─packages
    │  ├─test-results
    │  │  └─test
    │  │      └─binary
    │  └─tmp
    │      ├─compileJava
    │      │  └─emptySourcePathRef
    │      ├─compileTestJava
    │      │  └─emptySourcePathRef
    │      └─jar
    └─src
        ├─main
        │  └─java
        │      └─com
        │          └─michaelssss
        └─test
            └─java
                └─com
                    └─michaelssss

idea能直接识别gradle项目，不用做额外配置

使用gradle简易动作：

gradle clean build test –fullstacktrace

完全拖拽的方式实现表创建及管理（但是相应的例外建立的模型，和SQL关系不清晰，且无文档）

Gradle解决依赖和版本管理；

发布仍旧为手工发布？（好像是）；

gitlab提供了版本管理流程；

平台提供所有组件，业务只需要Gradle引入相应的项目自动解决依赖（貌似看上去挺爽的）；

又因为平台提供了所有组件，或者称为服务，所以内部普遍采用RPC的方式；

有自有wiki；

目测缺少bug track，用wiki暂时顶着（好像是）

gitlab提供了版本管理流程

由以上带来的缺点是：

新手入门还是很有成本的。

Gradle是要学习的新东东，另外Gradle不像ant那么的简单，但是可以从maven借鉴大量的概念来学习

没有显式的RPC调用语句，黑箱带来了一定程度上的阅读困难，特别是跨project的调用压根看不到服务提供者的实现细节，从而缺少了注释说明。