分层架构是运用最为广泛的架构模式， 几乎每个软件系统都需要通过层来隔离不同的关注点，以此应对不同的需要变化，使得这种变化可以独立进行，此外，分层架构模式还可以用于隔离业务复杂度和技术复杂度。 Robert Martin认为单一职责原则就是”一个类应该只有一个引起它变化的原因”，换句话，就是如果有两个引起类变化的原因，就需要分离。单一职责原则可以理解为架构原则， 这里我们考虑的不是类，而且层次，这就是为什么我们需要将业务和基础设施进行分开的原因。 分层架构演进 左边为传统的经典三层架构，在此基础上，领域驱动里面提出了四层架构，由原来的业务层分为应用层和领域层。 “新增的应用层”主要负责：协调对领域对象的操作，分配工作，与其它系统的应用层进行交互的必要渠道, 本身不包括业务逻辑, 是非常薄的一层， 与业务用例一一对应 领域层： 负责表达业务概念，业务状态信息以及业务规则。 基础设施层： 向其他层提供通用的技术能力， 为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件等。 分层依赖关系 一般的分层架构都是，上层依赖下层，从上自下的依赖关系， 但是DDD中，我们推荐应该 ...

我们常常在开发中，需要连接数据库，然而数据库的安全组，一般都是受限制的（为了做网络隔离，只有特定的网段能够访问），比较好的做法就是通过跳板机或者堡垒机来做代理，以下就是如何在liunx-like系统和windows系统中进行代理访问的配置。 下载私钥将堡垒机的SSH私秘，下载并保存在本地的私钥目录，例如 ~/.ssh/jump-server-pri.key ###修改权限chmod 600 ~/.ssh/jump-server-pri.key Linux-like 系统下在终端中使用如下的命令, 将在后台建立到数据库的连接通道： 1ssh -fNT -L 5432:XXXX.rds.cn-northwest-1.amazonaws.com.cn:5432 -i ~/.ssh/jump-server-pri.key dbuser@52.xx.xx.xx 本命令借助了SSH的轻量级代理机制 - -L参数会在本地监听一个端口，转发数据到远程主机上 本地测试通过如下命令，进行端口监听检查： 1lsof -nP -i4TCP:5432 | grep LISTEN 本地所有访问127.0.0.1: ...

代码规范 包名请用单数 资源名称一般用单数 资源URL用复数 整体变量和方法的命名请使用驼峰规范 使用lombok，取代Getter，Setter和toString 实体可以统一继承AbstractEntity 实体的ID生成器，可以使用工具类里面的生成器，SnowflakeIdGenerator或者UUIDGenerator request.XXXDTO用于数据的接收和字段校验, response.XXXDTO可以统一使用ResponseDTO封装. 应用层包括（Rest或者Controller和DTO），业务层包括（Service，实体和资源库接口），基础设施层（具体的技术实现） Restful风格 场景 动作 路径 响应 创建一个标准 POST /api/v1/standards/ 201， 400， 401， 403，5XX 获取标准列表 GET /api/v1/standards/ 200, 400， 401， 403， 5XX 获取某一个标准详情 GET /api/v1/standards/{standard_id} 200， 401， 403， 5 ...

背景如果只是在一台主机或者虚拟机上面运行一个容器，那么Docker命令行就足够了，e.g: docker run xxximage。 但是如果需要管理一个100X的容器集群，就比较有挑战了。在AWS众多服务中，就有提供集群资源管理和服务调度的服务，比如EKS和ECS, 由于EKS还没有进入中国区，本篇博客重点介绍在ECS上面运行基于Spring Cloud全家桶的微服务架构。 ECS的工作原理我们将基于上面的ECS架构图，简单介绍下ECS的一些重要组件和工作原理。 ECS agent, 在每一个实例，它都有一个运行的docker进程，它就是ECS agent, 其主要负责接收ECS的命令，并且将这些命令转化为docker对应的命令；所以它能够控制EC2实例，什么时候启动、停止容器并且监控已经使用的和空闲的资源情况。 ECS pause, 第一启动的容器，协调以后容器进行协议的分配，防止冲突。 Cluster mangement Engine负责协调整个集群的实例，它可以被认为是虚拟的资源池，比如内存、存储、CPU、网络等；所以通过它，能够知道整个集群的资源现状。 Scheduler ...

背景根据一份报告显示，大约80%的安全问题发生在应用层，但是在应用层的投入相对匮乏。 造成上面的原因很多，其中比较突出和普遍的原因就是研发团队没有足够的安全意识，常常把安全放在最后，作为一种nice to have的事情，由于交付压力，安全测试常常被砍掉。 自动化安全之前常常通过新闻的渠道才知道某某库出现了安全漏洞，然后通过手动的方式去查看，这种方式非常的耗时，低效。 所以我们做自动化安全，把安全相关的检测和测试，集成到jenkins流水线中，持续的获取到我们应用的安全状态，并做持续改进，避免安全造成的公司财务或者名誉损失。 自动化流水线： 源码安全扫描常见的源码级别的静态安全扫描有Fortify（收费）,FindSecurityBugs,Sonar+FindBugs,通过这些工具，它们可以快速识别代码中的安全风险，并给出修复提示。如图“Sonar+FindBugs插件”： 具体配置请参考：https://find-sec-bugs.github.io/ 第三方依赖安全监测工具180%的代码不是你写的，而来至于第三方依赖 比如知名的Apache structs2有一个版本就有远程代码 ...

背景前段时间，做了一个关于如何集成Office365的调研，探索如何将它集成到应用里面，方便多人的协同工作，这种应用场景特别在内部审计平台使用特别多，一些文档需要被不同角色查看，评论以及审批。 技术方案简介通过快速的调研，发现已经有比较成熟的方案，其中之一就是微软定义的WOPI接口，只要严格按照其定义的规范，并实现其接口，就可以很快实现Office365的集成。 上面架构图，摘取至http://wopi.readthedocs.io/en/latest/overview.html，简单讲讲，整个技术方案，共有三个子系统： 自建的前端业务系统 自建的WOPI服务 - WOPI是微软的web application open platform interface-Web应用程序开放平台接口 Office online 我们可以通过iframe的方式把office online内嵌到业务系统，并且回调我们的WOPI服务进行相应的文档操作。 界面界面的原型，通过iframe的方式，把office 365内嵌到了我们的业务页面，我们可以在这个页面上，多人协同对底稿进行查看和编辑。 样例代 ...

战术设计在DDD中，分两部分，战略设计和战术设计，战略设计很好的帮助我们理清问题域，划分服务，具体可参见： 领域驱动设计：服务划分。今天我们重点聊聊战术设计，如何通过它，指导我们的编码，着眼于单个界限上下文。 概念篇在战术部分，DDD有很多的概念，这里我们聊聊一些重要的概念，各个概念所在层级和调用关系如下： 应用服务 很薄的一层， 与业务用例一一对应，非CRUD 协调代理的作用 其本身不包含业务逻辑 可以作为事务的边界1234567891011121314151617181920212223242526272829303132@Servicepublic class UserApplicationService { private static Logger logger = LoggerFactory.getLogger(UserApplicationService.class); @Autowired private UserRepository userRepository; @Autowired private EmailService ...

Mysql存储引擎 MyISAM，不支持事务、也不支持外键，但其访问速度快，对事务完整性没有要求。 InnoDB，提供了具有提交、回滚和崩溃恢复能力的事务安全。但是比起MyISAM存储引擎，InnoDB写的处理效率差一些并且会占用更多的磁盘空间以保留数据和索引。 MEMORY， 使用存在内存中的内容来创建表。 每个MEMORY表只实际对应一个磁盘文件。MEMORY类型的表访问非常得快，因为它的数据是放在内存中的，并且默认使用HASH索引。 表连接的类型 Left Join Right Join Inner Join Full Join（Do not support） 临时表的使用一旦涉及排序和分组，就很大可能会使用临时表，而临时表分两类： 内存临时表 - MEMORY Engine 磁盘临时表 - MyISAM Engine 根据临时表的大小（tmp_table_size），mysql会决定使用哪种临时表；众所周知，内存的IO速度远远超过了磁盘的IO速度，所以在做优化的时候，尽量避免使用磁盘临时表的情况。 常见优化方式 先定位慢查询 show status like ‘sl ...

分布式事务产生的原因 数据库分库分表 微服务化 在微服务架构中，每个服务在用本地事务的时候，知道自己执行的事务是成功还是失败，但是无法知道其他服务节点的事务执行情况，因此需要引入协调者TM，负责协调参与者RM的行为，并最终决定这些参与者是否把事务进行提交。 随着微服务架构的流行，让分布式事务问题日益突出， 那么常见的分布式事务解决方案有哪些呢？ 如何理解最终一致性和它的事务补偿机制呢？ 刚性事务 - 强一致性 如上图，这是个标准的全局事务，事务管理器控制着全局事务，管理事务的生命周期，并通过XA协议与资源管理器协调资源；资源管理器负责控制和管理实际的资源 （这里的资源管理器，可以是一个DBMS，或者消息服务管理系统） 两阶段提交它是XA用于在全局事务中协调多个资源的机制，常用于事务管理器和资源管理器之间，解决一致性问题，分两阶段： 提交事务请求 执行事务请求 2PC的问题 效率低，与本地事务相比，XA协议的系统开销比较大（数据被锁定的时间跨度整个事务，直到全局事务的结束），只有支持XA协议的资源才能参与分布式事务。 2PC是反可伸缩模式的，在事务处理过程中，参与者需要一直持有资 ...

定义 RxJava extends the observer pattern to support sequences of data/events and adds operations that allow you to compose sequences together declaratively while abstracting away concerns about things like low-level threading, synchronisation, thread-safety and concurrent data structures. RxJava简单来说是建立在观察者模式上面的编程范式，它一定程度抽象和屏蔽了低层的线程创建管理和多线程并发安全问题，从而提供更好的编程体验，降低了开发者使用门槛。 一些概念 一切皆是Stream，那么什么是流呢？ Stream可以简单理解为按时间排序的Events序列, 其中Observable 就是一个Stream, 它是不可变的，任何操作都会返回一个全新的Stream， 这种Immutability性，很好的规避了 ...