什么书讲的什么

《设计数据密集型应用》 又名《数据密集型应用系统设计》

乍一看本书是教你写后端应用呢,实际的内容比这个高到哪里去了 

当我们在设计后端应用的时候,围绕的往往根本还是数据处理、存储、展示,那么这“数据大陆”的全貌是什么呢?


第一部分

在单机数据库中数据库系统会面临哪些挑战

数据库有哪些模型,有哪些查询方式

底层的存储结构是什么,如何高效的检索数据

编码格式

第二部分

在分布式数据库中会涉及的基本概念

分布式系统中会有哪些麻烦事,如何化解

一致性和共识分布式系统中的核心


第三部分

在大数据运用中实事数据(业务表亦或事实表)数据是如何衍生的

批处理

流处理

以及“数据大陆”未来发展

最后作者还在数据隐私保护方面做了一些讨论


本书抽丝剥茧,高屋建瓴。从问题的根本开始,掌握这些“源头”可以让架构选型和设计做的更好

比较难能可贵的是本书不是一堆各种术语堆砌,而是循序渐的让你从麻烦到破解,从而引导你“攻破”麻烦,然后你就自然而然的能看懂“术语”了。

看看网友的评价
本书为数据系统的设计、实现、与评价提供了很好的概念框架。读完并理解本书内容后,读者可以轻松看破大多数的技术忽悠,与技术砖家撕起来虎虎生风🤣。 —— Vonng
提纲挈领  —— 介错
我想给这本书打一百颗星。(截取) ——  brokilon    


那么哪里可以看呢
你可以在线免费阅读: https://github.com/Vonng/ddia/ (非官方的中文翻译版)要买纸值的看豆瓣:https://book.douban.com/subject/30329536/ (原作者授权中文翻译出版)

2018年微服务服务治理现状

目前就2种方案

1. 服务治理框架方案,基于业务代码侵入式的方案

单语言最全 Java体系的 Spring Cloud 全家桶套餐 优:成熟大规模验证 劣: 单语言,其他语言接入麻烦
支持多语言的 Tars(腾讯) 服务治理框架 优:腾讯十余年的服务治理经验的开源输出,框架本身完整 劣:只能在平台上玩,外部生产案例较少
其他语言自实现的,如PHP的Swoole方案,Golang的Gokit、GoMicro等 优: 自主可控,随意定制 劣: 需要基础架构团队来hold
其他的一些RPC框架,因为不是一套的服务治理框架这里不谈

本方案最大的劣势是业务代码侵入,要潜入一大堆业务无关的代码,维护客户端的成本也非常巨大

2. ServiceMesh服务网格方案,以Istio为代表的以SideCar(边车)流量代理的方案

Istio背后由IBM和Google共同支持,被誉为下一代的服务治理框架
全套解决方案,服务治理需要的功能统统都有,默认需要运行在Kubernetes上

宜人贷有部分业务已经线上使用 (宜人贷Kubernetes 容器云实践方案 https://mp.weixin.qq.com/s/Mn0TWdiuJSiYw5DlBlT61g)
支付宝公司蚂蚁金服也在持续探索中 (蚂蚁金服大规模微服务架构下的Service Mesh探索之路 http://www.servicemesher.com/blog/the-way-to-service-mesh-in-ant-financial/)
其他有实践的公司: 优信二手车

据公开的资料显示,唯品会,新浪微博都是采用SideCar(边车)流量代理的方式做的多语言接入
Sidecar就是ServiceMesh的雏形

本方案最大的优势是0业务代码侵入,现有业务项目可以直接接入,同时天下没有免费的午餐,最大的劣势是复杂,需要懂操作系统,懂网络,懂容器,懂Kubernetes
后续如果Istio在云上成熟,配套的管理工具成熟,能一定程度降低门槛,让业务开发在OPS上解放出来。

学习推荐

  • IBM 微讲堂 Istio 系列 https://developer.ibm.com/cn/os-academy-istio/
    目标听众:对微服务治理感兴趣的企业决策者、技术调研者、架构师、技术开发人员、运维人员等。
  • 免费的Istio在线实验平台 https://www.katacoda.com/courses/istio
  • 中文用户 ServiceMesher 社群 http://www.servicemesher.com/blog/

在很多开发环境,只有NFS存储支持,NFS容易搭建获得。
NFS本身不支持 Storage Classes 的动态申请存储空间
需要一个 nfs-client-provisioner 从而让NFS也具有 Storage Classes 动态分配申请存储空间的能力

安装NFS Server 服务器端

略过,自己搭建,我使用的是群晖提供的NFS服务
10.8.8.2:/volume1/k8s

Rancher(K8S) node节点

所有node安装mount nfs客户端支持
yum install -y nfs-utils

mount -t nfs 10.8.8.2:/volume1/k8s /mnt/
确保node节点可以挂载nfs

启用额外的Rancher Catalogs

Global 》 Catalog 》
Helm Stable(Enable)
Helm Incubator (Enable)
注意启用后需要等10多分钟才能看到Catalogs里面的内容

启用nfs-client-provisioner 从而支持NFS Storage Classes

Global 》 Catalog 》 Launch
搜索 nfs-client-provisioner 》 View Details
add Answer
nfs.server:10.8.8.2
nfs.path:/volume1/k8s

设置

Global 》 Cluster 》 Storage 》Storage Classes 》
nfs-client 》 Set as default

好了现在可以愉快的部署Catalogs 或者 helm 的应用了, 需要持久化的应用能自动的在NFS共享中开辟新的文件夹存储空间了

 

原文:44 engineering management lessons 

作者:Slava Akhmechet 
翻译:Aladdin

译者注:作者是RethinkDB的联合创始人 – 一个开放源码的分布式数据库,旨在帮助开发人员和运营团队使用非结构化数据构建实时应用程序。以下为译文:

欢迎来到工程管理课程。它生动有趣,艰难有益 ,最重要的是它能给你带来全新的技能!以前你认为有用的管理技巧现在可能不灵了。你必须获得一套全新技能,并在这个过程中摆脱一些不良的习惯。接下来提供一个让你入门的小指南。

需要做的

  1. 吸引,培养和留住人才。与工程师交流,尽快整理出问题,然后尽可能的解决这些问题。
  2. 和每个工程师沟通,了解他们紧接着要处理的最重要的问题是什么。
  3. 当开发团队之间无法达成共识时,站出来成为最后的决定者。
  4. 成为信息中心。了解每个工程师在做什么,尽可能的连接团队里的每个人。
  5. 提供行政支持。安排问题,协调发布,确保官僚体系能够正常运转。
  6. 执行行为和绩效标准。开除行为恶劣及表现不佳的员工。

尽量避免

  1. 一个人埋头处理问题并强行制定规则。当你不得不写下一些准则来保证高效的工程开发,这恰恰就是你制定规则权力的终结。
  2. 监督员工的工作质量和数量。软件工程不是装配线。如果你发现自己经常监督,那仅仅是因为你没有吸引到合适的人才,并给予他们正确的激励。

动机和文化

  1. 你是招聘和决定的人。您的团队发生的一切都是您的责任。
  2. 工程是卖方市场:人们为你工作,因为他们相信你。获取他们的才华是你的一种特权。
  3. 权威不是随便就能获得的。它是随着时间的推移,在不断做出正确决定的过程中积累出来的。
  4. 不到万不得已,千万不要做决定。尽可能让团队自己探索想法并作出决定。
  5. 做必要的决定。几乎没有东西能够比一个无法取得突破的团队还要沮丧。
  6. 不要随便否定一个想法。创造一个每个人都觉得能安全共享和探索想法的环境。写代码的员工有很多你不了解的想法。依靠你的团队,你会做出更好的决断。
  7. 建立起关于如何做出良好决定的直觉,这种直觉95%是来自于你和团队的良好关系。多如牛毛的概念框架在如何管理工程团队上并没有太大作用。它们仅仅是让优秀的管理者更优秀,糟糕的管理者更糟糕。

情绪和人的管理

  1. 就像其他的技能一样,在我们的日常文化中,管理常常伴随着威望。威望容易让人分心 – 它常常伴随着决断的轻率和随意。越早跳出威望的陷阱,你就越能专注于自己的工作。
  2. 管理活动也常常招致鄙视。你要做的就是忽略它 ,因为一般认为管理者是无用的人,压根就不了解怎样创建一个成功的人类组织。
  3. 一旦你觉得有问题,你可能是对的。你要做的是避免受外界事物的干扰,不忽略你的感受。
  4. 如果你发现自己正在指责某人,你也有可能做错了。没有人早上醒来就准备把事情搞砸。大多数时候你能通过与人交流感受解决问题。
  5. 大多数人不会轻易分享他们的情绪。和员工多进行些非正式的谈话,梳理工作中可能出错的地方。然后尽可能的修复它。
  6. 你的团队期待你的领导。你应该有勇气站出来说出一些员工不敢说的东西。
  7. 发现和解决你的团队不太注意的文化问题是值得的。敢于说出每个人都应该知道但实际上他们不知道的一些文化习俗。
  8. 雇用行业大牛,并且完全信任他们。按季度或月来评估员工表现,迫不得己可以开除员工。不要每天都评估员工表现,这会让你和他人都会疯掉的。
  9. 大多数智力活动都受潜意识里情绪的干扰。一旦你清楚这些东西,你的管理将会更加高效。

应对打击和冲突

  1. 不要太快做判断,你远没你想象的知道的多。即便你确定你是完全正确的,也请你听完所有人的意见。
  2. 在听完所有人的意见之后,总结他们的观点,争取能让人们说出“谢谢,这正是我想要表达的做法”这样的话来。归纳大家相一致的意见,并说明你从每个人那里学到的东西。然后做出你的决定。
  3. 做出决定后,立马执行。不要让团队把时间浪费在安抚团队内少数持反对意见的人。
  4. 执行过程中,有重要新信息出现,重新召集成员讨论解决方案。
  5. 当碰到有人不接受这些有理有据的决定时,分歧就会演变成冲突。
  6. 大多数冲突的发生是因为人们感觉被忽视。所以你要坐下来问每一个成员的感受,认真听取他们的反馈,然后总结一下他们的回复,并向他们再三确认。大多数时候这样会解决问题。
  7. 如果你在合理的距离内听取了每个人的意见并处理了问题,冲突仍然存在,那么是时候开始一段艰难的谈话了。

困难对话

  1. 尽快开启困难对话。等待只会使情况更糟。
  2. 不要假定或武断的下结论。不要在你心中妖魔化人。永远不要大声苛责,诽谤别人。
  3. 使用非暴力的沟通 – 这是我所知道的最好的方法来批评人们的行为,而不会冒犯他们。它看起来似乎像一个管理潮流,但真的很有用(我保证)。
  4. 有勇气说出你的感受和需要。人们因为表现出自己脆弱的一面而相互吸引,虽然这个做法是被自己排斥。但请记住脆弱性并不是弱点。
  5. 期待人们给予你同样的礼貌。当你陈述你的需要和感觉时,别人的反映让你感觉不舒服,这往往告诉你需要将关注点放在他们身上而不是你自己身上。

不可触碰的底线

  1. 人们会试图试探发现的你的底线。这时你只要知道什么时候该承担责任,什么时候该坚定想法就成功了一半。
  2. 偶尔有人会做得太过火了。当他们这样做时,你必须表明这个底线不能触碰,否则你将失去你在团队里的权威。
  3. 一个类似“你这样做,我感觉不舒服”这样坚定的回答通常就足够了。
  4. 如果你不喜欢他们的所作所为,那就别笑了。敢于表现出你的真实情感。
  5. 如果你总是对同一个人说“你这样做,我感觉不舒服”,那么是时候开除这个人了。
  6. 除非你是一个反社会的人,否则开除人就会很艰难,你会找借口说服自己不要这样做。如果你一直觉得某人并不适合这个岗位,就请你勇敢做你该做的事。
  7. 不要让外界压力迫使你做决定,外界会让你为你的决定负起相应的责任,他们做法无可厚非。自己做的决定就应该承担相应责任。
  8. 相信自己。如果连你自己都认为你在马上的姿态滑稽可笑,显然你是不能领导骑兵的。

使用工具来检查项目代码对PHP7的兼容情况

使用 PHP_CodeSniffer + PHPCompatibility
PHP_CodeSniffer
PHP_CodeSniffer对PHP,JavaScript和CSS文件进行标记,并检测违反已定义的一组编码标准的行为。
https://github.com/squizlabs/PHP_CodeSniffer

PHPCompatibility
PHP兼容性检查
https://github.com/PHPCompatibility/PHPCompatibility
更多PHPCompatibility相关内容,请参考 https://www.sitepoint.com/quick-intro-phpcompatibility-standard-for-phpcs-are-you-php7-ready/

安装和运行

按照官方文档进行安装
先安装PHP_CodeSniffer
再安装插件PHPCompatibility

composer global require “squizlabs/php_codesniffer=*”
phpcs –config-set installed_paths /data/wwwroot/php/PHPCompatibility
phpcs –config-set installed_paths “D:\projects\php\PHPCompatibility”

查看是否安装上
phpcs -i
#The installed coding standards are MySource, PEAR, PSR1, PSR12, PSR2, Squiz, Zend and PHPCompatibility
执行检查
phpcs –standard=PHPCompatibility –runtime-set testVersion 7.0 /data/wwwroot/project/ >phpcs.log
#执行的过程会有些慢,慢慢等吧

根据phpcs.log中的日志,解决error级别的错误

FILE: \data\wwwroot\project\Common\function.php

FOUND 3 ERRORS AFFECTING 2 LINES

9 | ERROR | Function split() is deprecated since PHP 5.3 and removed since PHP 7.0; Use preg_split() instead
11 | ERROR | Function eregi() is deprecated since PHP 5.3 and removed since PHP 7.0; Use preg_match() instead

11 | ERROR | Extension ‘ereg’ is deprecated since PHP 5.3 and removed since PHP 7.0; Use pcre instead

再加上手动按照PHP版本逐级检查不兼容

PHP5.4.x 》 PHP5.6.x

从 PHP 5.4.x 迁移到 PHP 5.5.x

不向后兼容的变更的检查
检查 pack() 和 unpack() pass

PHP 5.5.x 中废弃的特性的检查
preg_replace() 函数中用到的 /e 修饰符现在被弃用。可以使用 preg_replace_callback() 函数来替代。
mcrypt 的相关函数

PHP 5.5.x 》 PHP5.6.x

从PHP 5.5.x 移植到 PHP 5.6.x
不向后兼容的变更的检查
严格的 json_decode()

PHP 5.6.x 》 PHP7.0.x

从PHP 5.6.x 移植到 PHP 7.0.x
不向后兼容的变更的检查
ereg相关函数
split()

测试

把主要业务功能都过一遍测试

升级部署问题

方式1:容器部署:php-fpm改用docker的方式部署,这样比较方便多版本切换和回滚
方式2:传统部署:部署新服,业务流量切过去,原有服暂时不要销毁,等业务没问题后再慢慢销毁原有服, 如果是云平台应该为所有将要销毁的系统做一个快照以备不时之需

本文提供
Windows系统下使用laradock作为开发运行环境, PhpStorm作为开发IDE, 如何配置xdebug 断点调试
OSX系统下使用laradock作为开发运行环境, PhpStorm作为开发IDE, 如何配置xdebug 断点调试

laradock中php-fpm 的xdebug.ini配置

laradock/php-fpm/xdebug.ini
如果是Windows系统则改为

如果是OSX系统则改为

xdebug.ini文件中其他参数不用动
xdebug.remote_host参数设置的是xdebug服务器的地址,这里实际上是“母鸡”也就是phpstorm的网络地址
xdebug.remote_connect_back这个参数如果为1表示根据请求来源“remote_host”,来发起调试,在docker环境下有网络nat所以不会成功,这个参数的改为0

phpstorm的配置

设置中> Languages & Frameworks > PHP
Debug 默认参数可以不动
Servers 中Name: laradock Host:你的网址 Port:80 Debugger:Xdebug
勾选 “Use path mappings” 把项目目录和laradock中 /var/www/你的项目 进行目录映射
phpstorm的xdebug配置不在累述,可以参见laradock http://laradock.io/documentation/#install-xdebug
laradock + phpstorm配置xdebug不成功多半是xdebug.remote_connect_back没设置为0