目前的项目使用前后端完全分离模式，前端
Vue后端Java-Dubbo-ZooKeeper，中间层Node-Moleculer。闲暇之余也来整理一下分布式系统和微服务架构中的一些知识点。
当下主流微服务架构分类
高性能
RPC技术和服务治理类，这个领域最强为ZeroC IceGrid，公司目前的Dubbo也属于这个分类，在这个分类中属于性能一般的RPC框架。以
HTTP REST为通讯机制的通用性微服务架构，比如Spring Cloud。基于容器技术的微服务架构平台，并不提供特定的
RPC通讯机制，比如Google的Kubernetes，这是一个微服务架构平台，理论上是让任何分布式应用都可以在平台上运行的。
说一些个人看法
分布式，微服务，集群和云计算这些高大上的名词几乎都有很密切的联系，工作接触了之后发现，这东西确实能在未来十多年内继续绽放光彩。从二十年前更传统的
IPC发展到十来年前的RPC诞生，同时SOAP-XML大放光彩后又在两三年前年前RPC变种REST-JSON替代，到今天还有人和我争执REST弊大于利，还有人和我大谈SOAP的优势。而如今2018年Spring Cloud开始兴起，作为JAVA程序员的你，还在观望什么呢？关于分布式系统中事务一致性的相关问题，这里我说说一些原理。事务最早是在银行业数据库中引入的，数据库事务要满足四个要求：
Atomic，Consistent，Isolation，Duration，其中原子性用于事务回滚，隔离性使用数据库互斥锁，加上持久性三者组成了数据库相关的大量I/O操作，及其耗费资源。如果一个事务要操作几个数据库服务器上的数据，这种事务就叫分布式事务，分布式系统编程难度很大，于是有人研究了一套分布式事务标准规范：
X/Open DTP。这个规范模仿TCP三次握手提出了二阶段提交模型2PC，这东西应该算这个行业内唯一全球工委的分布式事务规范了。上面提到的三种微服务架构也只是在各自领域被开发者们奉若神明，并没有采纳到国际开发标准中。微服务架构的三种体系：
Monolith Architecture,Microservices Architecture和Mix Architecture。巨石模式下请求通过API Gateway网关服务 后就能看到一堆Services，微服务模式下所有服务都通过Transporter进行通讯，这也就是消息中间件。混合模式下就是将许多服务进行的分类部署。关于微服务架构中各服务之间的通讯问题。我们引入的
Transporter实际上就是一个中转站，以前有人使用文件系统，也有人使用内存映射，都是为了处理分布式事务一致性而采取的措施。目前比较成熟的方案是使用消息中间件，可以是TCP，Redis，RabbitMQ，NATS，Kafka等等。
