Java,Python,C & C++常用工具总结

1.java语言

  • 常用的IDE:IntelliJ IDEA(强烈推荐),Eclipse
  • Guava: 谷歌的Java工具包,应用广泛
  • Curator:Netflix公司开源的一个Zookeeper client library,用于简化Zookeeper客户端编程,现在已经是apache下的一个独立项目了。Spark的HA也用的这货。
  • FindBugs: 代码静态分析工具,找出代码缺陷
  • Java反编译工具:Luyten,JD-Gui
  • Drools: 规则引擎
  • Jersey: Java RESTful 框架
  • Web开发相关:Tomcat、Resin、Jetty、WebLogic等,常用的组件Struts,Spring,Hibernate,mybatis,springmvc
  • Netty: 异步事件驱动网络应用编程框架,用于高并发网络编程比较好(NIO框架,spark 1.2.0就用netty替代了nio)
  • jOOQ:java Orm框架
  • Janino: 超级小又快的Java编译器,Spark的Tungsten引起用的它
  • Gephi:复杂网络分析软件, 其主要用于各种网络和复杂系统,动态和分层图的交互可视化与探测开源工具
  • Nutch:知名的爬虫项目,hadoop就是从这个项目中发展出来的
  • web-harvest:Web数据提取工具
  • POM工具:Maven+Artifactory
  • Shiro:安全框架
  • parboiled:表达式解析
  • dubbo: 阿里巴巴出品的分布式服务框架
  • jackson databind: json序列化工具(fastjson,simplejson)
  • Atomikos: 分布式事务管理
  • BoneCP:性能很赞的数据库连接池组件,据说比c3p0快好多
  • S-99:Scala相关的99个问题

 

2.Python

PyCharm:个人认为很好的一个IDE

PyWin:Win32 api编程包

numpy:科学计算包,主要用来处理大型矩阵计算,还有SciPy。

GUI:PyQt,PyQwt

supervisor:进程监控工具

PyGame: 基于Python的多媒体开发和游戏软件开发模块

Web框架: Django 开源web开发框架。

 

3.C和C++

Thrift:用来进行可扩展且跨语言的服务的开发。

libevent:是一个事件触发的网络库,适用于windows、linux、bsd等多种平台,内部使用select、epoll、kqueue等系统调用管理事件机制。(对了还有个libev呢)

Boost:C++标准库

Valgrind\Ptmalloc\Purify: 调试工具

breakpad:崩溃转储和分析模块.

UI界面相关:MFC、BCG和QT,高端一点的还有Html和DirectUI技术:libcef、HtmlLayout、Duilib、Bolt,集成了node和webkit内核。

Bootstrap 从 v3 升级到 v4 的时候你最应该注意的地方

升级到 v4

Bootstrap 4 几乎是对整个项目进行了重写。其中最显著的变化都概括到了下面的内容,与以前相比,拥有了更多的具体的类以及把一些有关的部分变成了相关的组件。

当心!它在 flux 中工作的时候和在 v4 alphas 进程中工作是一致的。只有当它在不完整的情况下,我们才会推送来帮助它保持在最新的状态。

总结

如下便是从 v3 升级到 v4 的时候你最应该注意的地方。

支持的浏览器

  • v4 现在放弃了对 IE8 以及 iOS 6 的支持,现在仅仅支持 IE9 以上 以及 iOS 7 以上版本的浏览器。如果对于其中需要用到以前的浏览器,那么请使用 v3.
  • 添加了对 Android v5.0 Lollipop 浏览器和 web 视图的官方支持。早期版本的 Android 浏览器和 web 视图仍然只有非官方支持。

全局变化

  • 对于 CSS 文件,从 LESS 切换到了 SCSS.
  • 对于主要的 CSS 单元,从 px 切换到了 rem.
  • 媒体查询现在是在 ems 中而不是 pxs 中。
  • 全局字体大小从 14px 增加到了 16px
  • 为 ~ 480px 及其以下添加了一个新的网格层。
  • 通过 SCSS 变量,可以使用可配置的选项来替换单独的可选主题 (例如,$enable-gradients: true)。

组件

  • 对于该包罗万象的新的组件,丢弃了面板,缩略图以及wells。
  • 丢弃了 Glyphicons 图标字体。
  • 丢弃了 Affix jQuery 插件。相反,我们推荐使用 position: sticky。如果想要查看 HTML5,请点击该这里,查看详细具体的填充代码建议。
  • 重构几乎所有的组件来使用更多的 unnested 的类而不是子选择器。

Misc

  • Bootstrap 不再支持非响应的用法。
  • 丢弃了在线定制器功能,支持更广泛的安装文件以及自定义的工程。

组件上的差别

重启

对于 Bootstrap 4 有一个新的部分——重启,即一个新的样式表,基于标准化的基础上再添加上我们自定义的重置样式。当使用 Element 对象的时候我们才会用到选择器——在这里没有类。它使用更模块化的方法将我们重置的样式和组件样式进行分离。它们包括了一些最重要重置比如一些边框尺寸边界的变化,许多元素从 rem 移动到 em 单元,链接样式,还有许多 element 对象中的变化。

版式

  • 将所有的 .text- utilities 移动到了 _utilities.scss 文件。
  • 完全删除了 .page-header 类。
  • .dl-horizontal 现在需要网格类,增加了列宽的灵活性。
  • 将自定义的<blockquote>样式移动到了类——.blockquote 和 .blockquote-reverse 修饰符中。

表格

  • 几乎所有实例的 > 符号都被删除了,意味着嵌套的表格现在将自动继承他们的父母的样式。这大大简化了我们的选择器和潜在的自定义设置。
  • 响应表不再需要包装元素。相反,仅仅只需要把 .table-responsive 放在 <table> 即可。
  • 考虑一致性,将 .table-condensed 重命名为 .table-sm
  • 添加了一个新的 .table-inverse 选项。
  • 添加了一个新的 .table-reflow 选项。
  • 添加了表头修饰符:.thead-default 和 .thead-inverse

表单

  • 将重置元素移动到了 _reboot.scss 文件夹。
  • 分别将 .input-lg 和 .input-sm 重命名为 .form-control-lg 和 .form-control-sm
  • 为了简单起见,现在删除了 .form-group-* 类,现在使用 .form-control-* 类。
  • 水平表单的检修:
  • 取消了 .form-horizontal 类的要求。
  • .form-group 类现在不再和 .row 混合,所以它现在需要网格布局。
  • 将一个新的 .form-control-label 类添加到了带有 .form-controls 的垂直中心标签中。

网格系统

添加了新的 ~ 480px 网格断点,意味着现在有五个总层。

按钮

  • 完全删除了 .btn-xs 类。

按钮组

  • 完全删除了 .btn-group-xs 类。
  • 删除了几乎所有的 > 符号,通过使用非嵌套类来实现更简单的样式。
  • 我们现在直接使用单独的 .navs, .nav-items, 和 .nav-links 类而不是像 .nav > li > a 这样的 HTML特定的符号。

Pager

  • 分别将 .previous 和 .next 重命名为 .pager-prev 和 .pager-next.

Panels, thumbnails, 和 wells

对于新的 card 组件,他们几乎全部被删除了。

Panels

.panel 改为 .card 将 .panel-default 删除并且不进行替换 .panel-heading 改为 .card-header .panel-title 改为 .card-title .panel-body 改为 .card-block .panel-footer 改为 .card-footer .panel-primary 改为 .card-primary 以及 .card-inverse .panel-success 改为 .card-success 以及 .card-inverse .panel-info 改为 .card-info 以及 .card-inverse .panel-warning 改为 .card-warning 以及 .card-inverse .panel-danger 改为 .card-danger 以及 .card-inverse

将 .item 更名为 .carousel-item.

文档

我们对文档也进行了升级,如下所示:

  • 我们还是使用 Jekyll,但我们在组合中配置了自定义插件:
  • example.rb 是默认插件 highlight.rb 的拷贝,它允许更容易的处理示例代码。
  • callout.rb 也是该插件类似的拷贝,但是它是为我特殊的文档标注所设计。
  • 为了更加轻松的编辑,所有文档内容都已经在 Markdown (而不是 HTML) 中被重写。
  • 为了让内容更简单,层次结构更清晰,所有页面被进行了重组。
  • 我们从普通的 CSS 改成了 SCSS,为了更好的利用 Bootstrap 的变量,mixins 极其更多内容。

新的部分

我们已经添加了以及改变了一些现有的组件。如下是新的或更新的样式。

组件 描述
Cards 一个新的、 更灵活的组件,它用来来取代 v3 中的的panels, thumbnails, 和 wells。
新导航栏 用一个新的、 更简单的组件替换以前的导航栏。
新进度栏 用现在的 <progress> 元素替换旧的 .progress < div >
新的变形的表 添加 .table-inverse, 表头选项, 用 .table-sm, and .table-reflow 替换 .table-condensed .
新的实用程序类

TODO: 审计了 v3 中不存在的新类。

移除的部分

下述组件在 v4.0.0 中被移除了。

组件 从 3.x.x 中移除 在 4.0.0 中相当于
Panels Cards
Thumbnails Cards
Wells Cards
Justified navs

TODO: v3 中的审计类在 v4 中不存在。

响应程序

下述已弃用的变量在 V4.0.0 被移除了:

  • @screen-phone、 @screen-tablet、 @screen-desktop、 @screen-lg-desktop。相反的,使用更多抽象的 $screen-{xs、 sm、 md、 lg、 xl}-* 变量。
  • @screen-sm@screen-md@screen-lg.相反,使用更明确地命名的变量 $screen-{xs,sm,md,lg,xl}-min 。
  • @screen-xs@screen-xs-min。这些额外的小断点有没有下限,因此,这些变量在逻辑上是荒谬的。根据 $screen-xs-max 改写你的表达式。

响应实用程序类也已经进行了彻底翻新。

  • 这些类(.hidden-xs .hidden-sm .hidden-md .hidden-lg .visible-xs-block .visible-xs-inline.visible-xs-inline-block .visible-sm-block .visible-sm-inline .visible-sm-inline-block.visible-md-block .visible-md-inline .visible-md-inline-block .visible-lg-block .visible-lg-inline .visible-lg-inline-block)都被删除了。
  • 它们被 .hidden-xs-up .hidden-xs-down .hidden-sm-up .hidden-sm-down .hidden-md-up .hidden-md-down .hidden-lg-up .hidden-lg-down 进行了替换。

当视区是在给定的断点或更大的范围内 .hidden-*-up 类将隐藏元素 (例如.hidden-md-up 会隐藏中型、 大型,和特大型设备上的元素)。

当视区是在给定的断点或更小的范围内 .hidden-*-down 类将隐藏元素 (例如.hidden-md-down 会隐藏超小尺寸、 中小型,和小型设备上的元素)。

当你想要让一个元素可见,你仅仅需要不把它隐藏在这样的屏幕尺寸下,而不是使用显示的 .visible-* 类。你可以结合一个 .hidden-*-up 类和一个 .hidden-*-down 类来在给定的时间间隔的屏幕尺寸上显示元素(如.hidden-sm-down .hidden-xl-up 仅在中型和大型的设备上显示元素)。

请注意,在 v4 中对网格断点进行更改意味着你需要让一个断点更大来实现相同的结果 (例如 和 .hidden-md-down 相比 .hidden-lg-down 和 hidden-md 更相似)。在一些不常见情况下,比如在元素的可见性不能表示为一个单一的连续范围的视区大小的时候,新的响应实用程序类不要试图去容纳它;相反的,您需要在这种情况下使用自定义的 CSS。

使用 Misc 来确定优先级

为视网膜显示器媒体查询删除 min--moz-device-pixel-ratio 黑客错误。 删除了 .hidden 和 .show,因为它在 jQuery 的 $(...).hide()拥有接口. 因为 IE 9 + 支持 :disabled,所以将 [disabled] 按钮改成了 :disabled。然而 fieldset[disabled] 仍然是必要的,因为本机禁用字段在 IE11 中仍然会存在问题

TODO: v3 中的事物审核列表被标记为已弃用。

附加说明

  • 删除了对样式嵌套表格的支持 (当前)

源文引用: http://wiki.jikexueyuan.com/project/bootstrap4/migration/

Jwt 中 token应该存储到哪里?

关于 token 的存储问题

JWT:
csrf 攻击无法获取第三方的 cookie,而是直接使用 cookie进行查询的时候会自动携带 cookie。
xss攻击通过代码注入可以获取 cookie。需要设置转义。
方式一、客户端使用 cookie直接认证,需要设置 cookie为 httpOnly,可以防止 xss攻击。但是无法防止 csrf攻击。需要设置伪随机数 X-XSRF-TOKEN
方式二、 客户端使用 auth授权头认证,token存储在 cookie中,需要防止xss攻击。可以防止 csrf攻击,因为必须获取到 cookie的值并放到 authorization,而 cookie不能跨域请求到。(适用于 ajax请求或者 api请求,可以方便的设置 auth头)
方式三、可以将token存储在 localstorage里面,在一个统一的地方复写请求头,让每次请求都在header中带上这个token, 当token失效的时候,后端肯定会返回401,这个时候在你可以在前端代码中操作返回登陆页面,清除localstorage中的token。(适用于 ajax请求或者 api请求,可以方便的设置 auth头)
设置 HTTPS,可以防止提交时的用户名或者密码被拦截或读取。

简化访问linux目录的方法

在 ~/.bashrc 加一行:

alias x86='cd /root/project/oskit/examples/x86'

source ~/.bashrc 以后(下次就不需要了)执行 x86 就切换过去了。

解析微服务架构(一)单块架构系统以及其面临的挑战

多年来,我们一直在技术的浪潮中乘风破浪,扬帆奋进,寻找更优秀的方法来构建IT系统,也一直在积极的学习并观察先进的公司如何以不同的架构方式构建或者优化其IT系统,来积极应对市场的变化,迅速做出响应,从而为客户提供更多的价值。

微服务架构模式(Microservice Architect Pattern)是近两年在软件架构模式领域里出现的一个新名词。虽然其诞生的时间不长,但其在各种演讲、文章、书籍上所出现的频率已经让很多人意识到它对软件领域所带来的影响。那到底什么是微服务,当我们谈论微服务时,它代表着一种什么样的含义?微服务适合应用在什么场景下,以及它有什么样的优缺点?微服务和SOA到底有没有区别?在接下来的几部分里,我将为大家揭开微服务的神秘面纱。

不过,在我们开始探讨微服务架构之前,让我们先回顾一下三层应用架构的发展历程并认识一下什么是单块架构应用。

  三层应用架构的发展

对于任何一个软件应用系统而言,其构建目标都是为了满足某类用户的需求,即为用户传递价值。一直以来,软件的架构设计是决定应用系统是否能够被正确、有效实现的关键要素之一。架构设计描述了在应用系统的内部,如何根据业务、技术、组织,以及灵活性、可扩展性、可维护性等多种因素,将应用系统划分成不同的部分,并使这些部分彼此之间相互分工、相互协作,从而为用户提供某种特定价值的方式。

  应用的三层架构

现实生活中,“层”这个字的含义,对大家一点都不陌生。我们经常说楼房高多少层,蛋糕有几层等。通常来说,层有好几种定义,但其中最耳熟能详的,莫过于“层”能帮助我们划分出构成某整体事物的,上下相互支撑的的不同部分。譬如说,我们喜欢吃的蛋糕,一般是由三层组成:第一层的蛋糕体、第二层的奶油,和第三层的水果。从顶部至底部,每一层依赖于下一层,从底部到顶部,每一层又支撑着上一层。

在软件架构模式的领域,经过多年的发展,也有了层的概念:

  • 层能够被单独构造;
  • 层具有区别于其他层的显著特点;
  • 层与层之间能够互相连接、互相支撑、互相作用,相互协作构成一个整体。
  • 层的内部,可以被替换成其他可工作的部分,但对整体的影响不大。

以WEB应用程序为例,在WEB应用程序开发的早期,由于受到面向过程的思维及设计方式的影响,所有的逻辑代码并没有明显的区分,因此代码之间的调用相互交错,错综复杂。譬如,我们早期使用的ASP、JSP以及PHP,都是将所有的页面逻辑、业务逻辑以及数据库访问逻辑放在一起,这是我们通常提到的一层架构。

随着JAVA,.NET等高级语言的快速发展,这些语言为开发者提供了越来越方便的的数据访问机制,如Java语言的JDBC、IO流,或者.NET的ADO.NET等。这时候,数据访问部分的代码逐渐有了清晰的结构,但表示逻辑和业务逻辑依然交织在一起,我们称这个阶段为二层架构阶段。

随着面向对象分析、面向对象设计、面向对象原则、设计模式、企业架构模式等理念以及方法论的不断发展,从为用户提供功能、以及有效组织软件结构的角度考虑,WEB 应用中不同职责的部分逐渐被定义在了不同的层次,每一层负责的部分更趋向于具体化,细致化,于是软件的三层架构逐渐出现了。三层架构通常包括表示层、业务逻辑层以及数据访问层。

  • 表示层表示层部分通常指当用户使用应用程序时,看见的、听见的、输入的或者交互的部分。譬如,有可能是信息的显示,音乐的的播放或者可以输入的文本框,单选按钮以及可点击的按钮等。通过这些元素,用户同软件进行交互并获取期望的价值。目前的用户接口大部分情况下为WEB方式,当然也可以是桌面软件的形式,例如. NET的WINFORM或者Java的SWING。
  • 业务逻辑层业务逻辑部分是根据用户输入的信息,进行逻辑计算或者业务处理的部分。业务逻辑层则主要聚焦应用程序对业务问题的逻辑处理,以及业务流程的操作,它是大部分软件系统区别与其他系统的核心。譬如,当用户点击一个按钮后,它可能会触发业务逻辑部分的代码进行运算,生成用户期望的结果。举例来说,在一个电子商务平台中,作为用户,当我们下单购买某个商品后,应用程序的业务逻辑层会对订单如何进行处理,如何计算折扣、如何配送等进行处理。
  • 数据访问层在用户同应用程序交互的过程中,会产生数据。这类数据需要通过某种机制被有效的保存,并在将来能够被重复使用,或者提供给其他系统。这种机制或者方法就是数据访问层最关注的部分。也就是说,它关注的是应用程序是如何有效的将数据存储到数据库、文件系统或者其他存储介质中。有一点要注意的是,它关心的是对原始数据的操作(数据库或者文本文件等存放数据的形式),而非原始数据的存储介质本身。譬如,在一个电子商务平台中,商品的信息是如何存储,图片的信息是如何获取的等。

三层架构的出现,一方面是为了解决应用程序中代码间调用复杂、代码职责不清的问题。其通过在各层间定义接口,并将接口与实现分离,可以很容易的用不同的实现来替换原有层次的实现,从而有效降低层与层之间的依赖。这种方式不仅有利于帮助团队理解整个应用架构,降低后期维护成本,同时也有利于制定整个应用程序架构的标准。

另一方面,三层结构的出现从某种程度上也解决了企业内部如何有效的根据技能调配人员,提高生产效率的问题。在大环境下,有效的分层能使不同职责的人员各司其职,更聚焦与个人专业技能的发展和培养。三层结构的出现不仅标准化了复杂系统的逻辑划分,更帮助企业解决了如何有效形成技术人员组织结构的问题,因此在很长的一段时间里,它一直是软件架构的经典模式之一。

  非三层架构

有些人认为,对于一个WEB应用程序,其被自动地分成了三层架构,因为它有三个分离的部件,如图所示:

这三个部分看起来虽然满足“层”的概念,但它并不是我们所说的软件架构的层。就像我们所说的奶油蛋糕,我们可以在蛋糕的底部加上稳固的底座,在蛋糕的外部加上漂亮的包装盒,但仔细想想,底座可以用不同品牌的底座,可以用纸质材料的,也可以用树脂材料的;包装盒可以用红色的一次性纸袋,也可以用蓝色的带着花纹的铁盒,它们并不是我们蛋糕组成的必须一部分。

浏览器可以独立存在与WEB应用程序之外,WEB应用程序也可以被不同的浏览器访问,因此浏览器不是WEB应用程序的部分。虽然最近几年,在浏览器端,我们可以使用很多JavaScript库或者框架独立开发前端应用,但它的范畴超出了我们目前讨论的三层架构,更多的属于富客户端以及前后端分离的应用。

类似的,数据库服务器也可以独立存在于应用程序之外,因此它也不是应用程序的一部分。虽然有些应用程序的逻辑代码,被设计成必须是在数据库中运行,例如存储过程或者触发器,但这种用法并不推荐,原因是将业务逻辑放在了数据库本身,大大增加了后期维护的复杂度和数据迁移的成本。

  单块架构应用

  什么是单块架构应用

虽然软件的三层架构帮助我们将应用在逻辑上分成了三层,但它并不是物理上的分层。这也就意味着,即便我们将应用架构分成了 所谓的三层,经过开发团队对不同层的代码实现,经历过编译(如果非静态语言,可以跳过编译阶段)、打包、部署后,不考虑负载均衡以及水平扩展的情况,最终还是运行在同一个机器的同一个进程中。对于这种功能集中、代码和数据中心化、一个发布包、部署后运行在同一进程的应用程序,我们通常称之为单块架构应用。典型的单块架构应用,莫过于传统的J2EE项目所构建的产品或者项目,它们存在的形态一般是WAR包或者EAR包。当部署这类应用时,通常是将整个一块都作为一个整体,部署在同一个WEB容器,如Tomcat或者Jetty中。当这类应用运行起来后,所有的功能也都运行在同一个进程中。

类似的,基于Ruby On Rails的单块架构应用,一般逻辑上分为控制器层、模型层以及视图层,同时代码存放在遵循一定层级结构 的目录中。当部署这类应用的时候,通常是使用SSH或者其他一些工具,如Capistrano将整个目录部署在Passenger或者其他WEB容器中。当这类应用运行起来后,所有的功能也都运行在同一个进程中。

因此,对于单块架构应用的定义,其实是基于分层软件架构设计的系统基础之上,从部署模式、运行模式角度去考虑的一种定义方式。

  单块架构应用的优势

  • 易于开发对单块架构的应用程序而言,开发方式相对较简单。首先从概念上,现有的大部分工具、应用服务器、框架都是这类单块架构应用程序,容易理解而且为人所熟知。如果从实践角度出发,现有的集成开发工具比较适合单块架构的应用程序,像NetBeans、Eclipse、IDEA等,它们都能够有效加载并配置整个应用程序的依赖,方便开发人员开发、运行、调试等。
  • 易于测试单块架构应用程序也非常容易被测试,因为所有的功能都运行在一个进程中,启动集成开发环境或者将发布包部署到某一环境,一旦启动该进程,就可以立即开始系统测试或者功能测试。
  • 易于部署对单块架构的应用程序而言,部署也比较容易。实际上,由于所有的功能最终都会打成一个包,因此只需复制该软件包到服务器相应的位置即可。当然,部署的方式可以有很多种,最简单的可以使用SCP远程拷贝到指定的目录下,当然也可以使用某些自动化的工具来完成。
  • 易于水平伸缩对单块架构的应用程序而言,水平伸缩也比较容易。实际上,由于所有的功能最终都会打成一个包,且只能运行在一个进程中,因此单块架构的水平伸缩,更确切的理解其实是克隆,即新建一个服务器节点,配置好该节点的运行环境,复制软件包到相应的位置,运行改应用程序。当然,必须要确保负载均衡器能采取某种分发策略,有效的将请求分发到新创建的节点。

  单块架构面临的挑战

随着最近几年互联网行业的迅猛发展,随着公司或者组织业务的不断扩张,需求不断的增加以及用户量的不断增加,单块架构的优势已逐渐无法适应互联网时代的快速变化,面临着越来越多的挑战。譬如说,一方面,随着业务的扩大,如何为用户提供可靠的服务,如何有效处理用户增多后导致并发请求数增多,导致的响应慢的问题,以及如何有效解决用户增多后带来的大数据量的问题等。另外一方面,随着公司或者组织业务的不断扩张,需求不断的增加,越来越多的人加入开发团队,代码库也在急剧膨胀。在这种情况下,单块架构的可维护性、灵活性在降低,而测试成本、构建成本以及维护成本却在显著增加。

  1.维护成本增加

随着应用程序的功能越来越多,团队越来越大,相应的沟通成本、管理成本、人员协调成本必然会显著增加。譬如说,对于使用Java编写的中型应用而言,当代码量为几万行时,可能只需要几人左右的团队维护。当代码量上升到几十万行级别时,可能需要几十人甚至是上百人的团队。

另外,随着应用程序功能的增多,当出现缺陷时,有可能引起缺陷的原因组合就会比较多,这也会导致分析缺陷、定位缺陷、修复缺陷的成本相应增高,也就意味着缺陷的平均修复周期可能会花费更长时间。

另外,随着代码量的增大,在开发人员对全局功能缺乏深度理解的情况下,修复一个缺陷,还有可能引入其他的缺陷,在自动化测试机制不完善的情况下,很可能导致该过程陷入“修复越多,缺陷越多”的恶性循环。

  2.持续交付周期长

随着应用程序的功能越来越多,代码越来越复杂,构建和部署时间也会相应的增长。在现有部署流水线稳定工作的情况下,对单块架构应用程序做任何细微的修改以及代码提交,都会触发部署流水线,对整个应用程序进行代码编译、运行单元测试、代码检查、构建并生成部署包、验证功能等,这也就意味着流水线的反馈周期变长,单位时间内构建的效率变低了。

另一方面,团队人员的增多,部署流水线运行的时间增加,开发人员能够提交代码的时间窗口就相应减少,(因为流水线运行的过程中,是禁止提交代码的),可能出现长时间等待代码提交,却无法提交的情况,极大破坏了团队的灵活性并降低了团队工作效率。几年前,我曾经工作在一个50万代码行的单块架构应用上,整个应用由一个50人左右的分布式团队负责。通常情况下,从开发人员提交代码到运行单元测试、构建发布包、运行功能测试、标记为可发布状态大概需要40分钟,时间稍微有点长,但团还能忍受。关键的问题是开发人员通常都是集中在下午3点左右,完成一定功能的情况下提交代码,结果就导致3点至5点那个时间段,成了代码提交的瓶颈,极大影响了该应用的持续集成和构建的效率。

  3.新人培养周期长

随着应用程序的功能越来越多,代码变得越来越复杂的同时,对于新加入团队的成员而言,了解行业背景、熟悉应用程序业务、配置本地开发环境,这些看似简单的任务,将会花费更长的时间。我曾经有个朋友,在加入一家世界500强的知名IT公司后,被安排到了一个百万级代码的产品组里。他花了将近1个月的时间来熟悉产品文档、配置开发环境后,才在本地成功的运行起了这个应用。在他从事这份新工作的头一个月里,我们好几次聊到他的新工作,得到的答案都是一样,“看文档,装环境”。对个人而言,花一个月时间来配置本地开发环境,其中的滋味和感受大家可想而知,我估计人世间比这更痛苦的事情也没几件了。而对公司或者部门而言,本期望员工花费数天就能配置好的环境,却花了一个月才能完成,这更是极大的浪费。更有甚者,在第一次配置完开发环境后,好几年都不愿意再升级或者重装系统,真是一招被蛇咬,十年怕井绳。

  4.技术选型成本高

传统的单块架构系统倾向采用统一的技术平台或方案来解决所有问题。通常,技术栈的决策是在团队开发之前经过架构师、技术经理慎重评估后选定的,每个团队成员都必须使用相同的开发语言、持久化存储及消息系统,而且要使用类似的工具。随着应用程序的复杂性逐渐增加以及功能越来越多,如果团队希望尝试引入新的框架、技术,或者对现有技术栈升级,通常会面临不小的风险。

另一方面,互联网行业不仅市场变化快,而且技术变化也快。譬如,短短几年几年时间,光前端JavaScript的框架,就出现了好几十个,从早一点的BackboneEmberAngularJSRactive等等。类似的,后端的框架、工具等也是层出不穷,有兴趣的朋友可以参考下ThoughtWorks的技术雷达(该技术雷达是ThoughtWorks对业界技术、工具、语言等发展趋势的分析以及预测报告)。因此,对单块架构的应用而言,初始的技术选型严重限制了其将来采用不同语言或框架的能力。如果想尝试新的编程语言或者框架,没有完备的功能测试集,很难平滑的完成替换,而且系统规模越大,风险越高。

  5.可伸缩性差

如果应用程序的所有功能代码都运行在同一个服务器上,将会导致应用程序的扩展非常困难。如果迫切的需要扩展,那么垂直扩展可能是最容易的(钱不是问题)。在大多数情况下,如果舍得砸钱上IBM的服务器、Oracle的数据库或者来自EMC的存储设备,不用改变一行代码,整个世界都变好了。不幸的是,伴随着业务的增长,数据的增长,垂直扩展会变得越来越吃力,成本越来越高。这也是为什么在业很多公司开始尝试使用开源,放弃这些昂贵的IOE产品的原因。这下明白为什么近几年去IOE的呼声越来越高了吧。

当考虑水平扩展时,通常的做法是建立一个集群,通过在集群中不断的添加新节点,然后借助前端的负载均衡器,将用户的请求按照某种算法,譬如轮转法、散列法或者最小连接法等合理的将请求分配到不同的节点上。但是,由于所有程序代码都运行在服务器上的同一个进程中,会导致应用程序的水平扩展成本非常高。譬如说,如果应用程序某部分的功能是内存密集型的,如需要缓存大量数据,而另外一部分功能是CPU密集型的,如需要进行大量的运算,那么每次实施水平扩展,运行该应用的服务器都必须有足够的内存和强劲的CPU来满足需求。因此,鉴于每个服务器都要提供该应用系统所需要的各种资源,基础设施的整体花费可能会非常高。当然,如果某些节点保持状态,如用户登陆后的会话信息等,更增加了水平扩展的难度。

  6.构建全功能团队难

最后,非常微妙的是,随着应用程序的功能越来越多,代码变得越来越复杂,其应用程序的复杂结构也会逐渐映射到研发团队的结构上。康威定律指出:一个组织的设计成果,其结构往往对应于这个组织中的沟通结构。单块架构的开发模式在分工时往往以技能为单位,比如UX团队、服务端团队和数据库团队,这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。譬如说,用户体验工程师(UX)更专注负责用户接口部分,业务层开发者则负责建立服务器后端的业务逻辑,数据库工程师和DBA们更关注数据访问组件和数据库。鉴于这些问题,随着时间的推移,不仅代码越来越难以管理,其对团队结构的影响也越来越明显。

综上所述,随着业务的不断扩大,需求功能的持续增加,单块架构已经很难满足业务快速变化的需要。一方面,代码的可维护性、扩展性、灵活性在降低;而另一方面,系统的测试成本、构建成本以及维护成本却在显著增加。因此,随着项目或者产品规模的不断扩大,单块架构应用的改造与重构势在必行。

  总结

互联网时代的产品通常有几类特点:创新成本低、需求变化快,用户群体庞大,它和几年前我们熟悉的单块架构应用有着本质的不同。随着市场变化快、用户需求变化快、用户访问量增加的同时,单块架构应用的维护成本、人员的培养成本、缺陷修复成本、技术架构演进的成本、系统扩展成本等都在增加,因此单块架构曾经的优势已逐渐无法适应互联网时代的快速变化,面临着越来越多的挑战。

  作者简介

  王磊,ThoughtWorks公司首席咨询师。开源软件的爱好者和贡献者,社区活动的参与者,Practical RubyGems的译者, GDCR西安的组织者。于2012年加入ThoughtWorks,为国内外诸多客户提供项目交付和咨询服务;在加入ThoughtWorks之前,曾就职过多家知名外企,具有丰富的敏捷项目实战经验。目前致力于微服务架构、虚拟化容器、持续交付、以及Devops的研究与实践。

微服务实战(一):微服务架构的优势与不足

这篇文章作者是Chris Richardson,他是早期基于Java的Amazonite EC2 PaaS平台CloudFoundry.com的创始人。现在他为企业提供如何开发和部署应用的咨询服务。他也经常在http://microservices.io上发表有关微服务的文章。

微服务正在博客、社交媒体讨论组和会议演讲中获得越来越多的关注,在Gartner的2014 Hype Cycle上它的排名非常靠前。同时,软件社区中也有不少持怀疑论者,认为微服务不是什么新东西。Naysayers认为这就是SOA架构的重新包装。然而,尽管存在着不同的争论,微服务架构模式却正在为敏捷部署以及复杂企业应用实施提供巨大的帮助。

  这篇博客是关于如何设计、开发和部署微服务的七篇系列文章中的第一篇。读者将会从中学到方法,并且和单体式架构模式(译者注:本文中会将 Monolithic翻译为单体)进行对比。这一系列文章将描述微服务架构中不同元素。你将了解到微服务架构模式的优缺点,以便决定是否更好的将微服务架构应用到自己的项目中,以及如何应用这一模式。

首先我们看看为什么要考虑使用微服务。

  开发单体式应用

假设你正准备开发一款与Uber和Hailo竞争的出租车调度软件,经过初步会议和需求分析,你可能会手动或者使用基于Rails、Spring Boot、Play或者Maven的生成器开始这个新项目,它的六边形架构是模块化的 ,架构图如下:

1.png
应用核心是业务逻辑,由定义服务、域对象和事件的模块完成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件,以及提供API或者UI访问支持的web模块等。

尽管也是模块化逻辑,但是最终它还是会打包并部署为单体式应用。具体的格式依赖于应用语言和框架。例如,许多Java应用会被打包为WAR格式,部署在Tomcat或者Jetty上,而另外一些Java应用会被打包成自包含的JAR格式,同样,Rails和Node.js会被打包成层级目录。

这种应用开发风格很常见,因为IDE和其它工具都擅长开发一个简单应用,这类应用也很易于调试,只需要简单运行此应用,用Selenium链接UI就可以完成端到端测试。单体式应用也易于部署,只需要把打包应用拷贝到服务器端,通过在负载均衡器后端运行多个拷贝就可以轻松实现应用扩展。在早期这类应用运行的很好。

  单体式应用的不足

不幸的是,这种简单方法却有很大的局限性。一个简单的应用会随着时间推移逐渐变大。在每次的sprint中,开发团队都会面对新“故事”,然后开发许多新代码。几年后,这个小而简单的应用会变成了一个巨大的怪物。这儿有一个例子,我最近和一个开发者讨论,他正在写一个工具,用来分析他们一个拥有数百万行代码的应用中JAR文件之间的依赖关系。我很确信这个代码正是很多开发者经过多年努力开发出来的一个怪物。

一旦你的应用变成一个又大又复杂的怪物,那开发团队肯定很痛苦。敏捷开发和部署举步维艰,其中最主要问题就是这个应用太复杂,以至于任何单个开发者都不可能搞懂它。因此,修正bug和正确的添加新功能变的非常困难,并且很耗时。另外,团队士气也会走下坡路。如果代码难于理解,就不可能被正确的修改。最终会走向巨大的、不可理解的泥潭。

单体式应用也会降低开发速度。应用越大,启动时间会越长。比如,最近的一个调查表明,有时候应用的启动时间居然超过了12分钟。我还听说某些应用需要40分钟启动时间。如果开发者需要经常重启应用,那么大部分时间就要在等待中渡过,生产效率受到极大影响。

另外,复杂而巨大的单体式应用也不利于持续性开发。今天,SaaS应用常态就是每天会改变很多次,而这对于单体式应用模式非常困难。另外,这种变化带来的影响并没有很好的被理解,所以不得不做很多手工测试。那么接下来,持续部署也会很艰难。

单体式应用在不同模块发生资源冲突时,扩展将会非常困难。比如,一个模块完成一个CPU敏感逻辑,应该部署在AWS EC2 Compute Optimized instances,而另外一个内存数据库模块更合适于EC2 Memory-optimized instances。然而,由于这些模块部署在一起,因此不得不在硬件选择上做一个妥协。

单体式应用另外一个问题是可靠性。因为所有模块都运行在一个进程中,任何一个模块中的一个bug,比如内存泄露,将会有可能弄垮整个进程。除此之外,因为所有应用实例都是唯一的,这个bug将会影响到整个应用的可靠性。

最后,单体式应用使得采用新架构和语言非常困难。比如,设想你有两百万行采用XYZ框架写的代码。如果想改成ABC框架,无论是时间还是成本都是非常昂贵的,即使ABC框架更好。因此,这是一个无法逾越的鸿沟。你不得不在最初选择面前低头。

总结一下:一开始你有一个很成功的关键业务应用,后来就变成了一个巨大的,无法理解的怪物。因为采用过时的,效率低的技术,使得雇佣有潜力的开发者很困难。应用无法扩展,可靠性很低,最终,敏捷性开发和部署变的无法完成。

那么如何应对呢?

  微处理架构——处理复杂事物

许多公司,比如Amazon、eBay和NetFlix,通过采用微处理结构模式解决了上述问题。其思路不是开发一个巨大的单体式的应用,而是将应用分解为小的、互相连接的微服务。

一个微服务一般完成某个特定的功能,比如下单管理、客户管理等等。每一个微服务都是微型六角形应用,都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI,运行时,每一个实例可能是一个云VM或者是Docker容器。

比如,一个前面描述系统可能的分解如下:

2.png
每一个应用功能区都使用微服务完成,另外,Web应用会被拆分成一系列简单的Web应用(比如一个对乘客,一个对出租车驾驶员)。这样的拆分对于不同用户、设备和特殊应用场景部署都更容易。

每一个后台服务开放一个REST API,许多服务本身也采用了其它服务提供的API。比如,驾驶员管理使用了告知驾驶员一个潜在需求的通知服务。UI服务激活其它服务来更新Web页面。所有服务都是采用异步的,基于消息的通讯。微服务内部机制将会在后续系列中讨论。

一些REST API也对乘客和驾驶员采用的移动应用开放。这些应用并不直接访问后台服务,而是通过API Gateway来传递中间消息。API Gateway负责负载均衡、缓存、访问控制、API 计费监控等等任务,可以通过NGINX方便实现,后续文章将会介绍到API Gateway。

3.png
·微服务架构模式在上图中对应于代表可扩展Scale Cube的Y轴,这是一个在《The Art of Scalability》书中描述过的三维扩展模型。另外两个可扩展轴,X轴由负载均衡器后端运行的多个应用副本组成,Z轴是将需求路由到相关服务。

应用基本可以用以上三个维度来表示,Y轴代表将应用分解为微服务。运行时,X轴代表运行多个隐藏在负载均衡器之后的实例,提供吞吐能力。一些应用可能还是用Z轴将服务分区。下面的图演示行程管理服务如何部署在运行于AWS EC2上的Docker上。

4.png
运行时,行程管理服务由多个服务实例构成。每一个服务实例都是一个Docker容器。为了保证高可用,这些容器一般都运行在多个云VM上。服务实例前是一层诸如NGINX的负载均衡器,他们负责在各个实例间分发请求。负载均衡器也同时处理其它请求,例如缓存、权限控制、API统计和监控。

这种微服务架构模式深刻影响了应用和数据库之间的关系,不像传统多个服务共享一个数据库,微服务架构每个服务都有自己的数据库。另外,这种思路也影响到了企业级数据模式。同时,这种模式意味着多份数据,但是,如果你想获得微服务带来的好处,每个服务独有一个数据库是必须的,因为这种架构需要这种松耦合。下面的图演示示例应用数据库架构。

5.png
每种服务都有自己的数据库,另外,每种服务可以用更适合自己的数据库类型,也被称作多语言一致性架构。比如,驾驶员管理(发现哪个驾驶员更靠近乘客),必须使用支持地理信息查询的数据库。

表面上看来,微服务架构模式有点像SOA,他们都由多个服务构成。但是,可以从另外一个角度看此问题,微服务架构模式是一个不包含Web服务(WS-)和ESB服务的SOA。微服务应用乐于采用简单轻量级协议,比如REST,而不是WS-,在微服务内部避免使用ESB以及ESB类似功能。微服务架构模式也拒绝使用canonical schema等SOA概念。

  微服务架构的好处

微服务架构模式有很多好处。首先,通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下,应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案,由此,单个服务很容易开发、理解和维护。

第二,这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术,提供API服务。当然,许多公司试图避免混乱,只提供某些技术选择。然后,这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术,他们可以选择现在的技术。甚至于,因为服务都是相对简单,即使用现在技术重写以前代码也不是很困难的事情。

第三,微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试,快速的部署变化。微服务架构模式使得持续化部署成为可能。

最后,微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于,你可以使用更适合于服务资源需求的硬件。比如,你可以在EC2 Compute Optimized instances上部署CPU敏感的服务,而在EC2 memory-optimized instances上部署内存数据库。

  微服务架构的不足

Fred Brooks在30年前写道,“there are no silver bullets”,像任何其它科技一样,微服务架构也有不足。其中一个跟他的名字类似,『微服务』强调了服务大小,实际上,有一些开发者鼓吹建立稍微大一些的,10-100 LOC服务组。尽管小服务更乐于被采用,但是不要忘了这只是终端的选择而不是最终的目的。微服务的目的是有效的拆分应用,实现敏捷开发和部署。

另外一个主要的不足是,微服务应用是分布式系统,由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于,他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事,但相对于单体式应用中通过语言层级的方法或者进程调用,微服务下这种技术显得更复杂一些。

另外一个关于微服务的挑战来自于分区的数据库架构。商业交易中同时给多个业务分主体更新消息很普遍。这种交易对于单体式应用来说很容易,因为只有一个数据库。在微服务架构应用中,需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择,不仅仅是因为CAP理论,还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法,从而对开发者提出了更高的要求和挑战。

测试一个基于微服务架构的应用也是很复杂的任务。比如,采用流行的Spring Boot架构,对一个单体式web应用,测试它的REST API,是很容易的事情。反过来,同样的服务测试需要启动和它有关的所有服务(至少需要这些服务的stubs)。再重申一次,不能低估了采用微服务架构带来的复杂性。

另外一个挑战在于,微服务架构模式应用的改变将会波及多个服务。比如,假设你在完成一个案例,需要修改服务A、B、C,而A依赖B,B依赖C。在单体式应用中,你只需要改变相关模块,整合变化,部署就好了。对比之下,微服务架构模式就需要考虑相关改变对不同服务的影响。比如,你需要更新服务C,然后是B,最后才是A,幸运的是,许多改变一般只影响一个服务,而需要协调多服务的改变很少。

部署一个微服务应用也很复杂,一个分布式应用只需要简单在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。相对比,一个微服务应用一般由大批服务构成。例如,根据Adrian Cockcroft,Hailo有160个不同服务构成,NetFlix有大约600个服务。每个服务都有多个实例。这就造成许多需要配置、部署、扩展和监控的部分,除此之外,你还需要完成一个服务发现机制(后续文章中发表),以用来发现与它通讯服务的地址(包括服务器地址和端口)。传统的解决问题办法不能用于解决这么复杂的问题。接续而来,成功部署一个微服务应用需要开发者有足够的控制部署方法,并高度自动化。

一种自动化方法是使用PaaS服务,例如Cloud Foundry。PaaS给开发者提供一个部署和管理微服务的简单方法,它把所有这些问题都打包内置解决了。同时,配置PaaS的系统和网络专家可以采用最佳实践和策略来简化这些问题。另外一个自动部署微服务应用的方法是开发对于你来说最基础的PaaS系统。一个典型的开始点是使用一个集群化方案,比如配合Docker使用Mesos或者Kubernetes。后面的系列我们会看看如何基于软件部署方法例如NGINX,可以方便的在微服务层面提供缓存、权限控制、API统计和监控。

  总结

构建复杂的应用真的是非常困难。单体式的架构更适合轻量级的简单应用。如果你用它来开发复杂应用,那真的会很糟糕。微服务架构模式可以用来构建复杂应用,当然,这种架构模型也有自己的缺点和挑战。

在后续的博客中,我会深入探索微服务架构模式,并讨论诸如服务发现、服务部署选择和如何分解一个分布式应用为多个服务的策略。

Redux-devTools简单的使用

Introducing

redux-devtools 是一个非常棒的工具,它可以让你实时的监控Redux的状态树的Store

Installation

npm install --save-dev redux-devtools
npm install --save-dev redux-devtools-log-monitor
npm install --save-dev redux-devtools-dock-monitor

Usege

创建DevTools组件

在你的App项目中,通过“Monitor(监视显示)”用createDevTools创建一个DevTools组件。示例用了最常用,最简单的LogMonitorDockMonitor

containers/DevTools.js

import React from 'react'

//从redux-devtools中引入createDevTools
import { createDevTools } from 'redux-devtools';

//显示包是单独的,要额外指定
import LogMonitor from 'redux-devtools-log-monitor';
import DockMonitor from 'redux-devtools-dock-monitor';

//创建DevTools组件
const DevTools = createDevTools(
  <DockMonitor toggleVisibilityKey='ctrl-h'
               changePositionKey  ='ctrl-q'>
    <LogMonitor theme='tomorrow' />
  </DockMonitor>
);

export default DevTools

DevTools.instrument()通过redux的compose来扩展store

createDevTools()创建的DevTools组件有个特殊的静态方法instrument(),它返回一个store的增强器,在开发中你需要在compose中使用。注意DevTools.instrument()要放在applyMiddleware后,因为你的applyMiddleware可以存在异步行为,为了确保所有的actions显示在store中,所以要放在后面

store/create.js

import {createStore,applyMiddleware,compose} from 'redux'
import rootReducer from './modules/reducers'

import thunk from './middleware/thunk'
import DevTools from '../containers/DevTools'

const enhancer = compose(
  //你要使用的中间件,放在前面
  applyMiddleware(thunk),
  //必须的!启用带有monitors(监视显示)的DevTools
  DevTools.instrument()
)

export default function createStoreWithMiddleware(initialState){
  //注意:仅仅只有redux>=3.1.0支持第三个参数
  const store = createStore(rootReducer,initialState,enhancer)
  return store
}

Render <DevTools /> in your App

import React from 'react';
import { render } from 'react-dom';
import { Provider } from 'react-redux';
import configureStore from './store/configureStore';
import TodoApp from './components/Counter';

//注意,不要直接这样做,要区分开发环境和生产环境
import DevTools from './containers/DevTools';

const store = configureStore();

render(
  <Provider store={store}>
    <div>
      <Counter />
      <DevTools />
    </div>
  </Provider>
  document.getElementById('app')
);

参考文档:redux-devTools

 

react native bind this 的两种方式

第一种带参数 bind this的方式(使用箭头方法)

    <TouchableOpacity
        onPress={(e) => this._needHandlderArgument(e,argument)}
        underlayColor='#00EE76'> 
    </TouchableOpacity >
      _needHandlderArgument(e, argument) {
          // 只处理argument  e用于绑定this

      }

第二种带参数 bind this的方式(直接带参bind)

    <TouchableOpacity
        onPress={this._needHandlderArgument.bind(this,argument)}
        underlayColor='#00EE76'> 
    </TouchableOpacity >
 _needHandlderArgument(argument) {
          // 只处理argument 

 }