编程之路

设计模式最经典的书籍自然是GOF的《设计模式》，但很多人的反应是这本书太难理解了，并不适合初学者阅读。这话说得在理。一方面，本书使用的C++示例难倒了一大群Java和.NET的开发人员；另一方面，这本书的风格过于专业化，更偏向于学术论文的风格（事实上，本书的雏形就是来源于GOF中Erich Gamma的博士论文），因此就显得有些晦涩难懂了。基本上，本书可以作为我们参考的标准，是经常查阅的文

现在许许多多的初学者和程序员，都在趋之若鹜地学习Web开发的宝典级框架：Struts2，Spring，Hibernate。似乎这些框架成为了一个人是否精通Java，是否会写J2EE程序的唯一事实标准和找工作的必备基础。然而，如果在面试的时候问这些程序员，你们为什么要学习这些框架？这些框架的本质到底是什么？似乎很少很少有人能够给我非常满意的答复。因为他们都在为了学习而学习，为了工作而学习，而

VO（View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。DTO（Data Transfer Object）：数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，我泛指用于展示层与服务层之间的数据传输对象。DO（Do

微服务（Microservices）—Martin Fowler【翻译】本文转载自：http://www.cnblogs.com/liuning8023/p/4493156.html原文是 Martin Fowler 于 2014 年 3 月 25 日写的《Microservices》。本文内容微服务 微服务风格的特性 组件化（Componentization ）与服务（Services） 围

最易懂的版本 Martin Fowler的这篇文章《》通俗易懂的讲解了什么是微服务架构.微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境

这是使用微服务构建应用的第四篇文章。第一篇文章介绍了微服务架构模式并讨论了使用微服务的优势和劣势，该系列的第二和第三篇文章 描述了微服务架构中通信的不同方面，本篇文章我们将密切讨论下服务发现的问题。为什么使用服务发现设想下，我们写了一些通过REST API或者Thrift API调用某个服务的代码，为了发起这个请求，你的代码需要知道服务实例的网络地址(IP 地址和端口号）。在传统运行在物理机器

这是使用微服务架构构建应用系列的第七篇也是最后一篇文章，第一篇文章介绍了微服务架构模式，并讨论了使用微服务架构的优势和劣势，接下来的文章讨论微服务架构的不同方面：使用API网关、进程间通信、服务发现、事件驱动的数据管理以及部署微服务，本篇文章，让我们看下如何把一个单体应用重构为微服务架构的应用。我希望这个系列的文章使你对微服务架构有一些好的理解，比如它的优势和劣势，何时使用微服务等 ，或许微服务

这是使用微服务架构构建应用系列的第六篇文章，第一篇文章介绍的微服务架构模式以及使用该模式的优势和劣势，接下来的文章讨论了微服务架构的不同方面：使用APi网关、进程间通信、服务发现以及事件驱动的数据管理。本篇文章我们将看一下有关微服务部署的策略。动机部署一个单体应用意味着对一个一般比较庞大的应用运行多个相同的拷贝，通常需要提供N台服务器（物理机或者虚拟机），并在每一台机器上运行M个应用实例。部署

这是使用微服务架构构建应用系列的第五篇文章.第一篇文章介绍了微服务架构模式并讨论了使用微服务的优势和劣势 ；第二篇和第三篇文章讨论了微服务架构不同层面的通信问题；第四篇文章密切探讨了服务发现的相关问题；本文章呢，我们换个口味，看看微服务架构模式中的分布式的数据管理问题。微服务与分布式数据管理问题一个单体应用一般只有一个关系型数据库，使用一个关系型数据的优势是应用可以实现ACID，为业务操作进行

这是使用微服务架构构建应用系列的第三篇文章。第一篇文章介绍了微服务架构模式并讨论了使用微服务的优势和劣势 ；第二篇文章介绍了应用的客户端如何通过API网关作为中介实现服务间的通信；在这篇文章中我们将看一看同一系统间的服务如何通信；第四篇文章主要介绍服务发现的问题。介绍在传统单体应用中，模块间使用编程语言级别的方法或功能彼此调用。然而微服务架构应用本质上是运行在多台机器上的分布式系统，每个服务都

对于设计、构建和部署微服务系列七篇文章的第一篇，我们介绍了微服务架构风格，讨论了微服务的优势和劣势，尽管微服务有些复杂，但仍然是构建复杂应用的一个明智选择，第二篇文章将讨论使用API网关构建微服务。当我们选择把应用构建成一组微服务的时候，我们需要决定应用的客户端如何与这些微服务进行交互。传统单体应用中，往往只是一组（一般是replicated，负载均衡）的节点，而在微服务架构中，每个微服务都会暴

微服务现在受到了大量的关注︰ 文章、 博客、 社交媒体和学术会议上的讨论都能看到该词汇的身影。微服务正迅速走向 Gartner Hype cycle 所指的快速发展期。同时，软件社区的一些怀疑论者指出微服务并不是什么新鲜玩意儿。这些唱反调的人说微服务和SOA概念并没有什么不同，旧瓶装新酒而已，顺势炒炒新概念。然而，不管说是夸大也好，怀疑也罢，微服务架构模式应用在敏捷开发和交付复杂的企业应用程序的时

互联网技术发展之路（2）- 业务如何驱动技术发展在《互联网技术发展之路（1） - 技术发展的驱动力》一文中，我们详细阐述了对于服务类的业务来说，业务发展是技术发展的驱动力。那接下来我们就看看业务究竟是如何驱动技术发展的。 互联网业务千差万别，但由于他们具有“规模决定一切”的相同点，其发展路径也基本上是一致的。互联网业务发展一般分为几个时期：初创期、快速发展期、竞争期、成

在系列文章的第2篇“互联网技术发展之路（2）- 业务如何驱动技术发展”中我们深入分析了互联网业务发展的一个特点：复杂性越来越高。复杂性增加的典型现象就是系统越来越多，当系统的数量增加到一定的程度，就由复杂度量变带来了复杂度的质变，主要体现在系统间相互依赖程度加深：比如说为了完成A业务系统，可能需要B、C、D、E等十几个其它系统进行合作。从数学的角度进行评估，可以发现系统间的依赖是指数级增长的，例如

上一篇博文《互联网技术发展之路（6）- 服务层技术剖析》中，介绍了互联网业务发展特点的中的“复杂性”的应对方式，本文介绍互联网业务发展特点的另外两个方面“高性能”、“高可用”。一般人提到高性能时第一想到的就是优化，提到高可用时第一反应就是双机或者备份，但是对于互联网这种超大容量和访问量的业务来说，这两个手段都是雕虫小技，无法应对互联网业务的高性能和高可用需求，互联网业务的高可用和高性能，需

互联网技术发展之路（5）- 开发层技术剖析1. 开发框架在系列文章的第2篇“BAT解密：互联网技术发展之路（2）- 业务如何驱动技术发展”中我们深入分析了互联网业务发展的一个特点：复杂性越来越高。复杂性增加的典型现象就是系统越来越多，不同的系统由不同的小组开发。如果每个小组用不同的开发框架和技术，将会带来很多问题，典型的问题有：1）技术人员之间没有共同的技术语言，交流合作少

互联网技术发展之路（4）- 存储层技术剖析1. SQL即关系数据。前几年NoSQL火了一阵子，很多人都理解为NoSQL是完全抛弃关系数据，全部采用非关系型数据，但事实经过几年的试验后，大家发现关系数据不可能完全抛弃，NoSQL不是No SQL，而是Not Only SQL，即NoSQL是SQL的补充。所以互联网行业也必须依赖关系数据，考虑到Oracle太贵，还需要专

大部分人对于BAT的技术有一种莫名的崇拜感，觉得只有非常牛逼和天才才能做出现在的这些系统，但经过前面两篇博文的分析，我们可以看到其实并没有什么神秘的力量和魔力融合在技术里面，而是业务的不断发展推动技术的不断发展，一步一个脚印，持续几年甚至10几年的发展，才能达到当前技术复杂度、先进性、牛逼度。抛开BAT各自差异很大的业务，站在技术的角度来看，其实BAT的技术架构基本是一样的，再