Docker (opens new window)是个划时代的开源项目，它彻底释放了计算虚拟化的威力，极大提高了应用的维护效率，降低了云计算应用开发的成本！使用 Docker，可以让应用的部署、测试和分发都变得前所未有的高效和轻松！
无论是应用开发者、运维人员、还是其他信息技术从业人员，都有必要认识和掌握 Docker，节约有限的生命。
本书既适用于具备基础 Linux 知识的 Docker 初学者，也希望可供理解原理和实现的高级用户参考。同时，书中给出的实践案例，可供在进行实际部署时借鉴。前六章为基础内容，供用户理解 Docker 的基本概念和操作；7 ~ 9 章介绍包括数据管理、网络等高级操作；第 10 ~ 12 章介绍了容器生态中的几个核心项目；13、14 章讨论了关于 Docker 安全和实现技术等高级话题。后续章节则分别介绍包括 Etcd、Fedora CoreOS、Kubernetes、容器云等相关热门开源项目。最后，还展示了使用容器技术的典型的应用场景和实践案例。
无论是应用开发者、运维人员、还是其他信息技术从业人员，都有必要认识和掌握 Docker，节约有限的生命。
本书既适用于具备基础 Linux 知识的 Docker 初学者，也希望可供理解原理和实现的高级用户参考。同时，书中给出的实践案例，可供在进行实际部署时借鉴。前六章为基础内容，供用户理解 Docker 的基本概念和操作；7 ~ 9 章介绍包括数据管理、网络等高级操作；第 10 ~ 12 章介绍了容器生态中的几个核心项目；13、14 章讨论了关于 Docker 安全和实现技术等高级话题。后续章节则分别介绍包括 Etcd、Fedora CoreOS、Kubernetes、容器云等相关热门开源项目。最后，还展示了使用容器技术的典型的应用场景和实践案例。
设计物联网系统是件有意思的事情，它需要考虑到软件、硬件、通讯等多个不同方面。通过探索不同的语言，不同的框架，从而形成不同的解决方案。在这里，我们将对设计物联网系统有一个简单的介绍，并探讨如何设计一个最小的物联网系统。出处：http://phodal.github.io/designiot/
本书不会重复造轮子，写出差异化，以实用性为初心，实例化引导为手段，避免阳春白雪式的理论宣导，或是皮相之谈的代码解读。总结而言本书的特点如下：
实例导向，理论为辅：笔者多年服务于互联网金融公司，本书以信贷系统这一真实项目为线索，循序渐进地介绍服务架构的来龙去脉，微服务架构的基础性理念介绍是必须的，但不会生搬硬套地解释某些知识点的设计原理，而会更加关注在架构演进过程中为什么要用到这些技术及这些技术的适用场景及局限。
言简意赅，拒绝话痨：对比国内外技术书箱，很大的差异在于国内很多作者喜欢“堆代码”，喜欢“旁征博引”，本书不求“厚”，但求“精”，对于一些显而易见或是网络中已有详尽介绍的知识点本书尽量以扩展阅读的形式呈现给读者，不占用过多篇幅介绍。
内容殷实，力求全面：在保证行文紧凑的同时，本书尽量覆盖服务架构的核心点、项目实例的全流程关键点，并且会引入一些相关的扩展话题以供探讨，IT技术的发展可能是各个行业中最快的，服务架构做为最重要的IT基础性技术之一自然也在快速地进化，所以本书也会用适当的篇幅用实例介绍目前比较业界被看好的Service Mesh及Serverless技术。
扩展丰富，追根溯源：本书以脚注或扩展阅读的形式引用了大量基础或发散性的解释说明做为知识体系的补充，引文力求正本清源，多为论文链接或权威网站（多见于Wikipedia、InfoQ、IBM）的一手资料。
实例导向，理论为辅：笔者多年服务于互联网金融公司，本书以信贷系统这一真实项目为线索，循序渐进地介绍服务架构的来龙去脉，微服务架构的基础性理念介绍是必须的，但不会生搬硬套地解释某些知识点的设计原理，而会更加关注在架构演进过程中为什么要用到这些技术及这些技术的适用场景及局限。
言简意赅，拒绝话痨：对比国内外技术书箱，很大的差异在于国内很多作者喜欢“堆代码”，喜欢“旁征博引”，本书不求“厚”，但求“精”，对于一些显而易见或是网络中已有详尽介绍的知识点本书尽量以扩展阅读的形式呈现给读者，不占用过多篇幅介绍。
内容殷实，力求全面：在保证行文紧凑的同时，本书尽量覆盖服务架构的核心点、项目实例的全流程关键点，并且会引入一些相关的扩展话题以供探讨，IT技术的发展可能是各个行业中最快的，服务架构做为最重要的IT基础性技术之一自然也在快速地进化，所以本书也会用适当的篇幅用实例介绍目前比较业界被看好的Service Mesh及Serverless技术。
扩展丰富，追根溯源：本书以脚注或扩展阅读的形式引用了大量基础或发散性的解释说明做为知识体系的补充，引文力求正本清源，多为论文链接或权威网站（多见于Wikipedia、InfoQ、IBM）的一手资料。
现今，尤其是在互联网领域，大多数应用都属于数据密集型应用。本书从底层数据结构到顶层架构设计，将数据系统设计中的精髓娓娓道来。其中的宝贵经验无论是对架构师，DBA、还是后端工程师、甚至产品经理都会有帮助。
这是一本理论结合实践的书，书中很多问题，译者在实际场景中都曾遇到过，读来让人击节扼腕。如果能早点读到这本书，该少走多少弯路啊！
这也是一本深入浅出的书，讲述概念的来龙去脉而不是卖弄定义，介绍事物发展演化历程而不是事实堆砌，将复杂的概念讲述的浅显易懂，但又直击本质不失深度。每章最后的引用质量非常好，是深入学习各个主题的绝佳索引。
本书为数据系统的设计、实现、与评价提供了很好的概念框架。读完并理解本书内容后，读者可以轻松看破大多数的技术忽悠，与技术砖家撕起来虎虎生风🤣。
在我们的社会中，技术是一种强大的力量。数据、软件、通信可以用于坏的方面：不公平的阶级固化，损害公民权利，保护既得利益集团。但也可以用于好的方面：让底层人民发出自己的声音，让每个人都拥有机会，避免灾难。本书献给所有将技术用于善途的人们。
计算是一种流行文化，流行文化鄙视历史。 流行文化关乎个体身份和参与感，但与合作无关。流行文化活在当下，也与过去和未来无关。 我认为大部分（为了钱）编写代码的人就是这样的， 他们不知道自己的文化来自哪里。
——阿兰·凯接受Dobb博士的杂志采访时（2012年）
作者： Martin Kleppmann
原名：《Designing Data-Intensive Applications》
译者：冯若航 （@Vonng）
校订： @yingang
繁体：繁體中文版本 by @afunTW
这是一本理论结合实践的书，书中很多问题，译者在实际场景中都曾遇到过，读来让人击节扼腕。如果能早点读到这本书，该少走多少弯路啊！
这也是一本深入浅出的书，讲述概念的来龙去脉而不是卖弄定义，介绍事物发展演化历程而不是事实堆砌，将复杂的概念讲述的浅显易懂，但又直击本质不失深度。每章最后的引用质量非常好，是深入学习各个主题的绝佳索引。
本书为数据系统的设计、实现、与评价提供了很好的概念框架。读完并理解本书内容后，读者可以轻松看破大多数的技术忽悠，与技术砖家撕起来虎虎生风🤣。
在我们的社会中，技术是一种强大的力量。数据、软件、通信可以用于坏的方面：不公平的阶级固化，损害公民权利，保护既得利益集团。但也可以用于好的方面：让底层人民发出自己的声音，让每个人都拥有机会，避免灾难。本书献给所有将技术用于善途的人们。
计算是一种流行文化，流行文化鄙视历史。 流行文化关乎个体身份和参与感，但与合作无关。流行文化活在当下，也与过去和未来无关。 我认为大部分（为了钱）编写代码的人就是这样的， 他们不知道自己的文化来自哪里。
——阿兰·凯接受Dobb博士的杂志采访时（2012年）
作者： Martin Kleppmann
原名：《Designing Data-Intensive Applications》
译者：冯若航 （@Vonng）
校订： @yingang
繁体：繁體中文版本 by @afunTW
斯坦福教授、Tcl 语言发明者 John Ousterhout 的著作《A Philosophy of Software Design》，自出版以来，好评如潮。按照 IT 图书出版的惯例，如果冠名为“实践”，书中内容关注的是某项技术的细节和技巧；冠名为“艺术”，内容可能是记录一件优秀作品的设计过程和经验；而冠名为“哲学”，则是一些通用的原则和方法论，这些原则方法论串起来，能够形成一个体系。正如”知行合一”、“世界是由原子构成的”、“我思故我在”，这些耳熟能详的句子能够一定程度上代表背后的人物和思想。用一句话概括《A Philosophy of Software Design》，软件设计的核心在于降低复杂性。
2个月的开发时间，微信后台系统经历了从0到1的过程。从小步慢跑到快速成长，经历了平台化到走出国门，微信交出的这份优异答卷，解题思路是怎样的？本文由张文瑞，微信后台团队出品。
在编程之余，有时候我就在想，什么样的程序员属于高级程序员呢？或者说，高级程序员 有哪些特性呢？工作年限一定不是一个关键的指标，许多工作多年的程序员依然写不出优雅的 程序。无论是在Android 开发还是其他领域，高级程序员一定是勤奋的，可以快速地掌握大量 的新技术、新框架，不仅懂得原理，还能把新的技术落地到公司的产品中去。这是衡量程序员 工作能力的一个重要标准，那么怎样才能将技术运用自如呢？唯有实践。基于此，我想把组件化 在日常实践中的一些大厂经典案例，编著成一本成体系的书，以便为想要进步的Android 程序员增 加更多的实战经验，这也是编写本书的核心目的所在。
编写本书的另外一个目的，是帮助程序员建立产品的思想，对于技术而言，孤立的存在是 没有任何意义的，技术只有与需求相结合，才能具有自身的价值。技术人员在开发的过程中， 要时刻了解所完成的功能可以为公司带来哪些价值，是提升用户的访问兴趣，还是提升用户的 使用流畅度，抑或是其他。当以产品思维去思考技术的时候，就会有动力、有目的地学习更多 有价值的技术，而不是哗众取宠地学一些“看似有用”的新技术。
编写本书的另外一个目的，是帮助程序员建立产品的思想，对于技术而言，孤立的存在是 没有任何意义的，技术只有与需求相结合，才能具有自身的价值。技术人员在开发的过程中， 要时刻了解所完成的功能可以为公司带来哪些价值，是提升用户的访问兴趣，还是提升用户的 使用流畅度，抑或是其他。当以产品思维去思考技术的时候，就会有动力、有目的地学习更多 有价值的技术，而不是哗众取宠地学一些“看似有用”的新技术。
微服务是继SOA后，最流行的服务架构风格之一。
按照微服务对系统进行拆分后，每个服务的业务逻辑都更加简单、清晰。服务之间是松耦合的，模块之间的边界也更加清晰。
微服务有效降低了软件项目的业务复杂程度，为小团队独立开发、持续交付和部署打下了良好的基础。
遗憾的是，微服务并不是银弹。与传统的单一架构相比，微服务架构对团队的组织架构、技术水平、运维能力等方面，都提出了更高的要求。如果没有掌握得当的方法而生搬硬套，微服务架构只会会适得其反－－降低项目的开发效率，这是本书的创作初衷之一。
在国内外的技术社区中，比较推崇现有开源方案，如"Spring Cloud全家桶"或者阿里开源的"Dubbo"。上述框架通常已经实现了服务发现、配置、负载均衡、限流熔断，等微服务架构所必须的的核心功能。
使用开源框架省却了造轮子的过程，但也降低了我们学习、思考的欲望。
为什么需要服务发现，又如何实现它呢？配置中心呢....思考和设计的过程充满了挑战，也是提升自身架构能力的一种手段。这是本书的创作初衷之二。
已有的微服务资料过于重视微服务的开发，忽略了微服务赖以生存的生态系统：工具链、自动化运维。可以说，离开了这两点的支持，微服务架构将难以落地。完善这两方面的思考和实战，是本书的创作初衷之三。
为此，我撰写了这本《从0到1实战微服务架构》。让我们"暂时忘掉"已有的、成熟的开源解决方案。尝试亲自动手，实现微服务架构的各个模块。
我们会从微服务开发、工具链、运维这三个角度，阐述微服务架构的实战方案。
由于篇幅、精力所限，本书无法写成一本”零起点”教程。我假设读者具有至少2年的服务端工作经验，并且了解以下技术或原理：
Git
Maven & Gradle
Docker & k8s
Java
Spring / Spring Boot
数据库: 如MySQL
消息队列: 如RabbitMQ
缓存系统: 如Memcached
内存数据库: 如Redis
本书可以供架构师、项目经理、高级服务端程序员参考、学习。
动手实战是本书的核心内容，因此本书所涉及的全部代码，都托管到了我的Github上(以lmsia-开头的项目)。
这些代码以研讨为主要目的，也可以直接应用于生产，但本人不对其稳定性负责。
按照微服务对系统进行拆分后，每个服务的业务逻辑都更加简单、清晰。服务之间是松耦合的，模块之间的边界也更加清晰。
微服务有效降低了软件项目的业务复杂程度，为小团队独立开发、持续交付和部署打下了良好的基础。
遗憾的是，微服务并不是银弹。与传统的单一架构相比，微服务架构对团队的组织架构、技术水平、运维能力等方面，都提出了更高的要求。如果没有掌握得当的方法而生搬硬套，微服务架构只会会适得其反－－降低项目的开发效率，这是本书的创作初衷之一。
在国内外的技术社区中，比较推崇现有开源方案，如"Spring Cloud全家桶"或者阿里开源的"Dubbo"。上述框架通常已经实现了服务发现、配置、负载均衡、限流熔断，等微服务架构所必须的的核心功能。
使用开源框架省却了造轮子的过程，但也降低了我们学习、思考的欲望。
为什么需要服务发现，又如何实现它呢？配置中心呢....思考和设计的过程充满了挑战，也是提升自身架构能力的一种手段。这是本书的创作初衷之二。
已有的微服务资料过于重视微服务的开发，忽略了微服务赖以生存的生态系统：工具链、自动化运维。可以说，离开了这两点的支持，微服务架构将难以落地。完善这两方面的思考和实战，是本书的创作初衷之三。
为此，我撰写了这本《从0到1实战微服务架构》。让我们"暂时忘掉"已有的、成熟的开源解决方案。尝试亲自动手，实现微服务架构的各个模块。
我们会从微服务开发、工具链、运维这三个角度，阐述微服务架构的实战方案。
由于篇幅、精力所限，本书无法写成一本”零起点”教程。我假设读者具有至少2年的服务端工作经验，并且了解以下技术或原理：
Git
Maven & Gradle
Docker & k8s
Java
Spring / Spring Boot
数据库: 如MySQL
消息队列: 如RabbitMQ
缓存系统: 如Memcached
内存数据库: 如Redis
本书可以供架构师、项目经理、高级服务端程序员参考、学习。
动手实战是本书的核心内容，因此本书所涉及的全部代码，都托管到了我的Github上(以lmsia-开头的项目)。
这些代码以研讨为主要目的，也可以直接应用于生产，但本人不对其稳定性负责。
软件模式是将模式的一般概念应用于软件开发领域，即软件开发的总体指导思路或参照样板。软件模式并非仅限于设计模式，还包括架构模式、分析模式和过程模式等，实际上，在软件生存期的每一个阶段都存在着一些被认同的模式。
本书使用图形和代码结合的方式来解析设计模式；
每个模式都有相应的对象结构图，同时为了展示对象间的交互细节， 我会用到时序图来介绍其如何运行；（在状态模式中， 还会用到状态图，这种图的使用对于理解状态的转换非常直观）
为了让大家能读懂UML图，在最前面会有一篇文章来介绍UML图形符号；
在系统的学习设计模式之后，我们需要达到3个层次：
能在白纸上画出所有的模式结构和时序图；
能用代码实现；如果模式的代码都没有实现过，是用不出来的；即所谓，看得懂，不会用；
灵活应用到工作中的项目中；
看懂UML类图和时序图
从一个示例开始
类之间的关系
时序图
附录
创建型模式
1. 简单工厂模式( Simple Factory Pattern )
2. 工厂方法模式(Factory Method Pattern)
3. 抽象工厂模式(Abstract Factory)
4. 建造者模式
5. 单例模式
结构型模式
1. 适配器模式
2. 桥接模式
3. 装饰模式
4. 外观模式
5. 享元模式
6. 代理模式
行为型模式
1. 命令模式
2. 中介者模式
3. 观察者模式
4. 状态模式
5. 策略模式
本书使用图形和代码结合的方式来解析设计模式；
每个模式都有相应的对象结构图，同时为了展示对象间的交互细节， 我会用到时序图来介绍其如何运行；（在状态模式中， 还会用到状态图，这种图的使用对于理解状态的转换非常直观）
为了让大家能读懂UML图，在最前面会有一篇文章来介绍UML图形符号；
在系统的学习设计模式之后，我们需要达到3个层次：
能在白纸上画出所有的模式结构和时序图；
能用代码实现；如果模式的代码都没有实现过，是用不出来的；即所谓，看得懂，不会用；
灵活应用到工作中的项目中；
看懂UML类图和时序图
从一个示例开始
类之间的关系
时序图
附录
创建型模式
1. 简单工厂模式( Simple Factory Pattern )
2. 工厂方法模式(Factory Method Pattern)
3. 抽象工厂模式(Abstract Factory)
4. 建造者模式
5. 单例模式
结构型模式
1. 适配器模式
2. 桥接模式
3. 装饰模式
4. 外观模式
5. 享元模式
6. 代理模式
行为型模式
1. 命令模式
2. 中介者模式
3. 观察者模式
4. 状态模式
5. 策略模式
如何基于K8S(Kubernetes)部署成PaaS/DevOps（一套完整的软件研发和部署平台）——教程/学习（实战代码/欢迎讨论/大量注释/操作配图），你将习得部署如：K8S(Kubernetes)、dashboard、Harbor、Jenkins、本地gitlab、Apollo框架、promtheus、grafana、spinnaker等。
注释及配图覆盖率达80%以上，旨在帮助快速入门。
并将告诉你：是什么（WHAT）、为什么这么做(WHY)、怎么做(HOW)。
建议学习时长1个月+，最终将实现点点点（自动化）的形式就能部署上线并维护。
注释及配图覆盖率达80%以上，旨在帮助快速入门。
并将告诉你：是什么（WHAT）、为什么这么做(WHY)、怎么做(HOW)。
建议学习时长1个月+，最终将实现点点点（自动化）的形式就能部署上线并维护。