Martin

在开始之前，我先卖个关子提一个问题：我们现在有一个Employee员工类。 [@Data](https://my.oschina.net/difrik) @AllArgsConstructor public class Employee { private Integer id; private Integer age; //年龄 private String gender; //性别 private String firstName; private String lastName; } 你知道怎么对一个Employee对象组成的List集合， 先按照性别字段倒序排序，再按照年龄的倒序 进行排序么？如果您不知道4行代码以内的解决方案（其实是1行代码就可以实现，但笔者格式化为4行），我觉得您有必要一步步的看下去。 一、字符串List排序 cities是一个字符串数组。 注意london的首字母是小写的。 List<String> cities = Arrays.asList( "Milan", "london", "San Francisco", "Tokyo", "New Delhi" ); System.out.println(cities); //[Milan, london, San Francisco, Tokyo, New Delhi] cities.sort

本文原文： Angular Architecture Patterns and Best Practices (that help to scale) 译者序 这是作为译者我想说的话，并非原文中的内容。 我猜此时此刻你心里的疑问一定是：为什么是 Angular，不是 React，不是 Vue，不是 Flux，不是 Redux ? 因为你已经对它们太熟悉了。 我个人作为开发者而言最希望是能够汲取到“圈外”的“营养”，这样才能给我的成长带来帮助。 我想对各位也是一样。 你不用担心因为不会 Angular 而看不懂这一些列文章，它们基本上谈论的是应用架构——关于设计、组织、抽象，很少会落到具体的实现，即使有，连蒙带猜也能推测出一二。这也能从侧面说明我衷心想推荐这些佳作的原因：通过大段大段的代码阐述很容易；难的是几乎不用代码来跨越语言的说明更高层次的东西，比如 Martin Fowler, Uncle Bob Martin 他们的文章就能如此。 我不评价框架的流行和好坏，我只是把一切呈现在各位的眼前。它们并非和 Flux，Vuex 大相径庭，反而你们会看到它们的影子，但更多的是不一样的东西。我在里面看到了更好的职责划分和抽象。 在文中我会以引用的格式和“译者注”开头穿插一些我的个人备注和带给我启发性的问题，你可以理解为文章的“评论音轨”，但其中问题我不会给予回答。你也可以忽略这些评论

一、分布式锁简介 锁 是一种用来解决多个执行线程 访问共享资源 错误或数据不一致问题的工具。 如果 把一台服务器比作一个房子 ，那么 线程就好比里面的住户 ，当他们想要共同访问一个共享资源，例如厕所的时候，如果厕所门上没有锁...更甚者厕所没装门...这是会出原则性的问题的.. 装上了锁，大家用起来就安心多了，本质也就是 同一时间只允许一个住户使用 。 而随着互联网世界的发展，单体应用已经越来越无法满足复杂互联网的高并发需求，转而慢慢朝着分布式方向发展，慢慢进化成了 更大一些的住户 。所以同样，我们需要引入分布式锁来解决分布式应用之间访问共享资源的并发问题。 为何需要分布式锁 一般情况下，我们使用分布式锁主要有两个场景： 避免不同节点重复相同的工作 ：比如用户执行了某个操作有可能不同节点会发送多封邮件； 避免破坏数据的正确性 ：如果两个节点在同一条数据上同时进行操作，可能会造成数据错误或不一致的情况出现； Java 中实现的常见方式 上面我们用简单的比喻说明了锁的本质： 同一时间只允许一个用户操作 。所以理论上，能够满足这个需求的工具我们都能够使用 (就是其他应用能帮我们加锁的) ： 基于 MySQL 中的锁 ：MySQL 本身有自带的悲观锁 for update 关键字，也可以自己实现悲观/乐观锁来达到目的； 基于 Zookeeper 有序节点 ：Zookeeper

注册中心--Eureka 相信通过 微服务应用开发入门①web端架构演进 童鞋已经大概知道注册中心的概念和它是做什么的； Eureka是Netflix开源的一款提供服务注册和发现的产品，它提供了完整的Service Registry和Service Discovery实现。 那我们还必须搞明白一些概念（当然其他概念还有很多很多） Register: 服务注册 服务的提供者，将自身注册到注册中心，服务提供者也是一个 Eureka Client。当 Eureka Client 向 Eureka Server 注册时，它提供自身的元数据，比如 IP 地址、端口，运行状况指示符 URL，主页等。 Renew: 服务续约 Eureka Client 会每隔 30 秒发送一次心跳来续约。 通过续约来告知 Eureka Server 该 Eureka Client 运行正常，没有出现问题。 默认情况下，如果 Eureka Server 在 90 秒内没有收到 Eureka Client 的续约，Server 端会将实例从其注册表中删除，此时间可配置，一般情况不建议更改 负载均衡 负载均衡是我们处理高并发、缓解网络压力和进服务端扩容的重要手段之一。 一般情况下我们所说的负载均衡通常都是指服务端负载均衡。 服务端负载均衡又分为两种，一种是硬件负载均衡，还有一种是软件负载均衡。 客户端负载均衡

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 我们经常谈论架构，讨论设计，却甚少关注实现和代码本身，架构和设计固然重要，但要说代码本身不重要，我不同意，Robert C.Martin大叔也不同意，Martin认为“源码即设计”。 在讨论具体的实施细则之前，我们不妨讨论一下什么是好代码?萝卜特 C.Martin认为：衡量代码质量的唯一标准是：WTF/min，也就是review代码的时候每分钟说“握草”的次数。这个定义虽有辱斯文，但粗野中不失奔放，调皮中又蕴含哲理。 好的代码如同文笔优美的散文，行云流水，赏心悦目，阅读的时候，如沐春风，带给人愉悦与启迪。 好的代码犹如构思精巧的小说，它或许不够平铺直述，却足够引人入胜，读到最后，你会豁然开朗，卧槽，原来是这样的啊，那一刻，你会觉得过程中的曲折和探索都是值得的。 好的代码，透过一个个函数，你仿佛可以窥视到作者有趣的灵魂;透过一行行代码，你仿佛在与一个充满智慧的朋友聊天，她总是条理清晰，逻辑严谨，有条不紊，娓娓道来。 而坏的代码，犹如病毒，它不仅瘫痪你的程序，还有很强的传播效应，等到它扩散开来，神仙难治。 坏的代码，像一个泥团，又或者像一座屎山，阅读的时候，你仿佛被困于黑暗的迷宫，又仿佛在跟一个絮絮叨叨的人交谈，她的脑回路经常短路，说话含混不清，主次不分，叨逼半天

本文最初发表在 Medium 博客，经原作者 Kesk -*- 授权，InfoQ 中文站翻译并分享。 1947 年 9 月 9 日下午 3:45，美国计算机科学家兼美国海军少将 Grace Murray Hopper 在 Harvard Mark II 计算机日志中记录了第一个计算机 Bug。她写道：“发现 Bug 的第一个实际案例。” 在这个领域不犯任何错误可能会很难，但幸运的是，并不是所有的错误都如此昂贵。在这份总结列表中，我收集了一些一直引起我注意的错误。 1. 亚利安 5 号运载火箭爆炸事件 1996 年 6 月 4 日，欧洲空间局（European Space Agency，ESA）发射的亚利安 5 号（Ariane 5）运载火箭在法属圭亚那的库鲁发射场发射后仅 40 秒就爆炸了。这枚火箭经过长达十年的研发，耗资 80 亿美元后进行首飞，但这一 Bug 的结果导致了 3.7 亿美元的损失。 首飞失败的原因是整数溢出，这是计算机编程中一个普遍存在的错误。在本例中，有人试图在 16 位空间中设置 64 位数字。 2. PayPal 意外向某人支付 92 千万亿美元 当 Chris Reynolds 打开他的 PayPal 电子邮件对账单时，这位宾夕法尼亚州公关主管的账户余额显示为 92,233,720,368,547,800 美元。 在 64 位数字的世界里，这个数字太过庞大

一、前言 前一篇文章 简单分析了微服务的好处，以及会带来的问题。 遇到问题并不可怕，可怕的是我们不去面对它，不去想办法解决它，逃避问题是不可能有任何进步。所以积极想办法应对问题并解决问题，才能不断的进步。 前面讲了，微服务一般都是由单体演进而来，很少有业务从0就开始进行微服务开发。如果能从0就开始用微服务开发，确实是一件很好的事情，前提是你确实考虑清楚了用微服务开发适合当前的业务以及业务的发展需求。 那么问题来了，企业什么时候引入微服务呢？ 二、企业什么时候引入微服务？ 引入原因 ： 单体应用无法满足业务增长的需求，业务的交付、业务的可靠性、稳定性要求，随着时间推移问题会越来越多。-- 也就是前面遇到的一些问题 不过也有人，不是从本公司业务发展，开发成本，开发效率来考虑问题，而是什么开发大会上看到很多公司微服务的演讲，或者听说很多公司在用微服务，从这些方面来考虑，也就是随大流，这种思考方式显然不是正确思考方式。不要为了微服务而微服务。采用微服务收益一定要大于单体应用，要能解决遇到的问题。 从单体架构升级到微服务架构，肯定希望提高研发效率，缩短工期，加快产品交付速度。 那他们在具体生产效率上有什么区别？ 根据马丁·福勒（Martin Fowler）的这篇 文章 ，揭示了生产率和复杂度的关系。 在复杂度较小时，单体应用的生产率更高，微服务架构反而降低了生产率。但是，当复杂度到了一定规模

　　 　　 大数据文摘出品 　　 作者：刘俊寰、牛婉杨 　　Facebook遭到了广告商们的集体抵制，股价下跌8%，小扎资产蒸发72亿美元。 　　6月26日，根据《华尔街日报》报道，消费品巨头 联合利华将在年底之前停止在Facebook、Instagram和Twitter上的所有广告支出 ，在这期间的广告投入将转移到其他媒体维持推广计划。 　　除了联合利华， 可口可乐也宣布暂停包括Facebook在内的全球社交媒体广告 ，自7月1日起，公司将暂停全球社交媒体平台上的所有广告，为期至少30天。 　　这到底是啥情况？广告商为何集体撤出Facebook？ 　　故事要从美国弗洛伊德事件说起。抵制种族歧视事件发生后， Facebook被指责对其平台上的仇恨性及歧视性言论监管不力， 不仅一直曝出种族歧视者的不善言论，对于相关广告和虚假视频也是有钱拿就收，完全不做鉴别。这就引起了一批“有良知”的”金主爸爸”们的不满。 　　这些看不惯的广告商们因此远而避之，大家联合起来成立了一个名为#StopHateforProfit（停止为赚钱不计手段）的运动， 希望小扎的旗下社交平台能够抵制种族歧视者的广告投放，不赚“黑心钱”。 　　 　　这个活动的发起方包括数十家大型零售和软件企业，目前又获得了包括支付企业、软件公司、零售500强等多家大企业的支持。 　　 　　在上周三，这些广告商集体在《洛杉矶时报

​ 黄小斜写了一年多的代码，渐渐地代码量也上来了，但是，代码写的多就是好吗，简单的数量堆积似乎并不能起到太好的效果，毕竟我们CRUD写多了，也不怎么需要架构设计，甚至连个设计模式都不怎么需要用到。如何开始代码精进之路，其实有很多的过来人早就已经给出了答案，今天就给大家推荐几本帮你精进代码的优质书籍，走过路过可不要错过哦~ 代码精进系列书单 ​ 代码精进之路：从码农到工匠 这是一本为专业程序员而写的书，写好代码、追求卓越和工匠精神是每个程序员都应该具备的优秀品质。 本书共有13章内容，主要分为技艺部分、思想部分和实践部分。技艺部分详细介绍了编程技巧和方法论，并配以详尽的代码案例，有助于读者提高编写代码的能力，优化代码质量。思想部分主要包括抽象能力、分治思想，以及程序员应该具备的素养等内容。实践部分主要介绍了常见的应用架构模式，以及COLA架构的设计原理。 作者简介 张建飞，阿里巴巴集团高级技术专家，Java全球管理组织（JCP）执行委员会正式会员（Full Member）。2007年计算机工程硕士毕业后，先后在软件公司InfoSys与互联网公司eBay担任高级研发和技术专家的职务。2014年加入阿里巴巴，先后在1688、ICBU和零售通担任技术主管。 作者精通面向对象技术，有丰富的一线编码实战和架构经验。特别是在应用架构、领域建模和复杂度治理领域，自研了COLA框架

微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。 二、微服务的优点： 1.每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。 2.微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。 3.微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。 4.微服务能使用不同的语言开发。 5.微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。 6.微服务允许你利用融合最新技术。 7.微服务只是业务逻辑的代码，不会和 HTML ,CSS 或其他界面组件混合。 三、微服务架构的缺点 1.运维要求较高。对于单体架构来讲，我们只需要维护好这一个项目就可以了，但是对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为我们无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求。 2.分布式的复杂性