抽象是用来处理复杂性的主要工具。一个问题越复杂，就越需要抽象来解决
设计模式这个术语是由Erich Gamma等人在1990年代从建筑设计领域引入到计算机科学的。在《Domain-Driven Terms》一书中，设计模式被描述为：
设计模式是命名、抽象和识别对可重用的面向对象设计有用的的通用设计结构。设计模式确定类和他们的实体、他们的角色和协作、还有他们的责任分配
每一个设计模式都聚焦于一个面向对象的设计难题或问题。它描述了在其它设计的约束下它能否使用，使用它后的后果和得失
最近上线了go语言写的一个接口服务，由于接口服务是分布式部署的，服务的配置就需要使用分布式配置中心来管理。在调研了其他配置中心工具方案后，最终采用了Consul作为配置工具。一方面其学习成本较低，二来Consul本身作为服务注册和发现工具，可以一次学习多次适用。
春节期间，公司组织远程培训，请Aws讲师培训Architecting on aws，属于aws架构培训中级课程。以下内容是个人做的笔记。
原文地址：10 Common Software Architectural Patterns in a nutshell
是否曾经好奇过大型企业系统是如何设计的？在主要软件开发之前，我们需要选择合适的架构，为我们提供所需的功能和质量属性。因为，在我们应用架构到我们的设计中之前，我们应该了解不同的架构
架构模式是对给定上下文中软件架构中常见问题的通用、可重用的解决方案。架构模式类似于软件设计模式，但范围更广。
原文地址：How to Build 12 Factor Microservices on Docker
原文由两部分构成，我和并处理了，并去掉原先两部分中间过渡的引语。文章有删减处理，有些地方确实拿捏不准，翻译可能南辕北辙，望见谅。最后感谢Google 翻译，完成了90%的翻译
随着企业持续从云计算上获得节约成本的好处，Devops团队正逐渐把他们的基础架构迁移到自服务平台。如何将应用设计成云原生和反脆弱成了至关重要的工作。在接下里的一系列文章里面，我们将研究用于应用设计的12要素方法论，以及怎样设计接口来和大部分流行的Pass提供者交互，以及演示怎么在Deis PaaS上运行一个微服务
由Netfix和Heroku等创新者的引领下，面向服务架构的数据中心正意识到在云上采用微服务的巨大潜力。Netfix是无可争议的第一个设计出可伸缩和反脆弱的应用，也就是有意引入chaos到他们的系统，他们的应用在面对错误时候变得更加稳定、弹性、优雅。同样通过帮助成千上万的客户在云上构建应用，Heroku提出一系列通用原则并将它描述成12要素方法论
Debounce 和 Throttle是javascript中两种手段来控制函数的执行，特别是事件的处理。
当处理scroll,resize, keyup等事件时候，由于每秒触发的时间频次太多，不断的通过绑定回调函数来处理，会对浏览器造成巨大压力。这时候Debounce和Throttle就派上用场了。
debounce强制函数某段时间只会执行一次，会把大量事件聚合在一次执行，哪怕它本来会被调用多次。
而throttle好比每隔15分钟一趟的电梯，过点不侯，debounce也每隔15分钟一趟，但当它看见有人要进来时候，它会允许进来，并从进来那一刻算起在等15分钟，如果15分钟内没有人进来了，就会开走。
在微服务架构实践中，一个难点是服务发现。每一个服务采用分布式部署，保证了拓展性和容错性，但带来了一个难点是如何监控这些服务，如何找到这些服务。
服务发现的种类有两种：客户端发现和服务端发现
客服端发现-客户端或者API网关查询注册中心获取服务的位置信息。支持服务注册的软件有Etcd，Zookeeper，Consul等
HTTP状态码(HTTP Status Code)是3位数字代码，用来表示服务器HTTP响应状态，它由RFC2616 规范定义的。所有状态码第一个数字代表其所属的状态分类。服务端返回响应数据时候，HTTP协议号和状态码作为Response line返回给客户端
在开发过程中，特别是基于RESTful架构，一个语义正确的HTTP状态码，显得十分有必要，它能够帮助客户端接受者能够从状态码快速甄别资源的状态。作为服务提供者，需要在客户端请求和服务的状态下选择一个正确的状态往往不是那么容易的事情。比如客户端访问一个受限的资源，返回401还是403就得细细考虑了。
原文地址：Top 6 Refactoring Patterns to Help You Score 80% in Code Quality
在过去做了不少代码审核，发现了一些代码质量上普遍存在的问题，以下是其中的前五名：
类之所以会臃肿，是因为开发者缺乏对最基本的编码原则，即“单一职责原则”（SRP）的理解。这些类往往会变得很臃肿，是由于不同的且在功能上缺少关联的方法都放在了相同的类里面。
解决方法：提取类/抽离方法 正如上面提到的，像“臃肿的类”（一个类提供了本该有几个类提供的功能）这种代码异味应该将原有类中的方法和属性移动到适当数目的新类中去。旧类中对应新类的方法和属性应该被移除。
另外，有时候一些类过于臃肿是因为它包含了被其他类使用本应该是其他类的成员方法的成员方法。这些方法也应该被迁移到合适的类中。
