永无止境，上下求索

REST(Representational State Transfer)  based Web Service是相对于传统的Web Service(SOAP+WSDL+UDDI)而提出的。传统的Web Service可以很好的解决异构系统之间的通信问题，但是需要首先定义好XML格式的合同(WSDL)，client和server都必须严格遵守协议，不容易升级以及集群伸缩。REST Web Serv

对于项目的开发和维护，私以为一致性是最重要的因素之一，甚至比一段牛逼的算法更能影响一个项目的成败。 一致性之于REST API的设计，那更是关键。无需追求最优方案，但希望大家API能够保持一致。先上例子Get /v1/users #获取所有用户Get /v1/users/1 #获取id为1的用户信息(记得返回值去掉敏感信息)

最近开发提现相关的功能，需要考虑幂等性。向社区取了点经，把自己的实现方法写下来。不会高谈阔论什么是幂等，幂等种类等高深的问题。只是简单的写下步骤，题目来源于此。为什么需要幂等分布式环境里面，网络不可控，计算机不可控，都有失败风险。先给定两个角色，server，client，client是请求发起者，server是请求接收者并处理业务逻辑。第一次请求任何地方失败了就直接告诉客户处理失败，这没有问题，但

需求背景最近接到一个项目，需要改造一个老的系统。该老系统以Oracle为存储，巨量的PL/SQL代码实现业务代码，C实现Socket Server，作为Client和PL/SQL的桥梁。不出所料，该老系统最大的问题是PL/SQL代码量巨大(上万的Procedure好几个)，且毫无组织可言，实在改不动了，其次是性能有问题。改动的方向是，把PL/SQL从Oracle中踢出，用Java改写相关业务逻辑，放

新型领导设计模式—设计可扩展性的业务架构开闭原则是软件设计最重要的原则之一，设计具有良好可扩展性的业务架构极其依赖该原则。业务品种在增多，已有业务自身也在发展，需要设计一套统一，灵活，互相独立的业务架构。笔者在多个项目中，多次使用新型领导设计模式来设计可扩展的业务架构，觉得有必要总结出来，以供大家参考。本来是想把该模式归为23种设计模式之一，可能是由于能力有限，没能成功。新型领导，把握大局(主流程)

计算机系统由硬件和软件组成，应用软件的命令，先转化为操作系统命令，再转化为汇编语言，最后再转化为二进制命令，由硬件来执行。软件要部署到硬件上才具有生命。Deployment Diagram展示的就是把什么样的软件部署到什么样的硬件上的过程，主体还是软件。因为关注的是部署，所以主体分割衡量标准就是，是否能够独立部署。Deployment Diagram里面的主体叫Node，用长方体来表示。下面讲从N

软件的架构设计，思路遵循由大及小。相较于Class Diagram，Package Diagram从更宏观的角度来展示软件的架构设计，主要体现在代码组织方面。Package Diagram对一些大型的项目特别有用。顺便说一句，良好的代码组织，对软件的可维护性至关重要，请认真的规划你的包结构。下文将简单介绍Package Diagram，主要分两块，什么是Package，以及Package之间的关系

类图是类的静态关系描述图，简单来讲有两个方面，有哪些类，这些类之间的关系是什么？需要注意的是类图描述的是静态关系，动态行为的如流程，判断，循环等类图无法描述，需要搭配其它UML图。类自身的描述生物由细胞构成，类图由类构成，我们先看看类长什么样，如何描述。首先类有一个唯一的名字，通常用手写字母大写的英文字母表示，一班名字应该用名词来表示。类的内部有两个部分构成，数据部门和操作部门。数据部门也

接触微服务也有几个月时间了，平时断断续续的会有一些关于微服务设计的思考，现在做个小结，与大家分享。先上一张简单的示意图底部是用到的数据存储设施，中间部分是今天的主角，微服务群，最上面是一个统一入口，网关。微服务应该分为核心微服务和业务微服务理想的系统应该是小核心，大业务。核心简单、精干、稳定；业务复杂、规则多、易变。业务调用核心，但是核心不会调用业务，需要的话可以走消息，解耦。 如图所示，微服务群