DEV Community: 小猫先生

对 IT 技术岗位的一点思考 Thoughts on IT posts

小猫先生 — Tue, 13 Feb 2018 09:13:58 +0000

在一个提供软件产品或互联网服务的公司，通过在技术部门对不同工作设置相应岗位，尝试让技术团队发挥出最大效能（出工）的同时创造出最大价值（出活）。
In a company which provides software products or Internet services, we set different IT positions according to various jobs in the technical department, try to build an efficient and effective team and ultimately output the most valuable things.

本人在 IT 行业工作数年，发现不少公司，不少人甚至高管对技术岗位的认识有偏差或错误，故写作本文，尝试更准确地描述不同的技术岗位，或许可以帮到一些人。
I have been working in IT companies for a few years, unfortunately, I found many people, including company executives, misunderstand the duties of IT posts. This essay tries to describe various technical positions more accurately and hopefully, it could help someone.

程序员，软件工程师 Programmer, Software Engineer

《我仍然是一名初级开发员吗？》对初级和中级程序员所应当具备的技术能力给与了分析和描述，摘录如下：
The article "Am I still a Junior Developer?" analyzed and described technical abilities that a junior and middle-level developer should comprehend and master, excerpts are below.

初级 Junior

理解基本编程概念 Understands basic programming concepts
开发代码时不太考虑性能和可维护性 Will produce code without keeping performance or maintainability in mind sometimes
会使用类库和框架，但并不总是理解相关工具实际做了什么以及它们是怎么做的 Can use libraries & frameworks but will not always understand what the tools are actually doing for them and/or how’s it doing them.
即便不理解，也会从网上（比如 stackoverflow.com）拷贝代码来使用，只要这些代码能工作 Might copy & paste code from the web (such as Stack Overflow) without understanding it, if it just works
偶尔会需要导师予以帮助 Will need occasional mentorship
工作受阻时，有时会担心别人认为自己不够好而不愿向他人寻求帮助（你是很不错的，寻求帮助很正常） Sometimes won’t ask for help when stuck because of fear thinking you’re not good enough (You are good! It’s ok to ask for help 😊)

中级 Mid-Level

深入地理解一门或更多编程语言 Understands one or more languages more deeply
编码时总会考虑性能和可维护性 Will produce code with thinking about performance & maintainability
使用工具时，理解它们做了什么，经常会考察工具源码来理解其工作方式，也会寻找缺少文档的工具的其他用法 Understands what the tools are doing for them, digs into the source code often to understand how it works & also finds undocumented usage of tools.
在考虑从网上拷贝代码之前，会先去理解它们 Will understand code found on the Web before even thinking about copying & pasting the code.
当工作受阻时总会去寻求他人的帮助 Will ask for help when they know they’re stuck (because asking for help is ok!)

高级 Senior

说起高级程序员，有时我也会像 Florian Rohrer 的一篇文字那样发出类似的疑问：《你什么时候可以说已经懂得一门语言？》对于高级程序员而言，相比于初中级，“高”在哪里？他是否一定要在各方面胜出？答案很明显是否定的，那么应当以怎样的标准进行衡量呢？
Speaking of a senior programmer, sometimes I would raise questions like Florian Rohrer asked in "When Can You Say You Know a Language?" Relative to junior & mid-level programmers, where can we find how "high" they are? Do they have to be head and shoulders above others in every aspect? Obviously, the answer is negative, but how could we measure it by what standards?

从技术的角度对初中高划分，其思路应当是横向+纵向的。比如对编程语言的语法，API 的认识，不仅要考察程序员对其准确性、相关性、优雅度这样的横向认知，也要考察其对语言、API 的发展历史的纵向认知。之所以作纵向考察，是因为这样能衡量出其对技术的关注度，是否会对发展逻辑作深入思考，从而对技术的走向有一定的前瞻性。纵向知识同时也表现出一个人知识范围的广度，不仅仅是本学科领域的知识，也包括其他领域。 From the perspective of technology, we need to consider it horizontal & vertical when facing the three levels. For example, for grammar/syntax of programming language, understanding of APIs, not only do we inspect a programmer how he looks at both of the aspects of accuracy, relevance, gracefulness horizontally, but vertically inspect depths and the history of them. The reason why we inspect the vertical side is, we could measure how much he concentrates on them, whether he would think of the logic of development deeply, subsequently, make trends of technology with extraordinary foresight. In many cases "vertical knowledge" demonstrates how wide a technical personnel's knowledge he has, including various knowledge in other realms.
从非技术的角度看，一个有着广泛知识的程序员（比如艺术音乐体育等），往往能借鉴其他领域学科的模式、解决方法来审视当前遇到的问题，从一个新的视角“更有创意地”解决问题。 From the perspective of non-technology, a programmer who masters wide knowledge, (art, music, sport, etc,.), he would probably learn patterns and solutions from other fields so that he could offer a solution more creatively with a new sight when dealing with problems.

《关于滨野纯的访谈》中谈到明星程序员的三种品质：
Three virtues/characters a star programmer should have when interviewing with 滨野纯:
1，最重要的第一点是，能够持之以恒地做某件事；First and foremost, be persistent when you start something.
2，拥有良好的直觉和品位。良好的直觉，这里是指面对一个新问题时，即使没有完整的解决问题也能够凭直觉提出正确的解决思路和方向。Processing good instincts and tastes. Good intuition means that when we are facing a new problem, we could raise correct solution ideas and directions even could not solve the problem utterly.
3，沟通能力。这个沟通能力不是说只要说明 “我想做什么” 就可以了，而是能够解释 “我的目标是什么” 以及我得出这一目标的整个思维过程，并且更重要的，是能够让其他人信服，简而言之就是能够将自己的目标明确传达给他人的人。Communication ability. This does not mean that it is sufficient if we tell others "what I want to do", but illustrate clearly "what is my goal" and the whole process how I formed the goal, and more importantly, make others convinced. In short words, it is an ability that we could articulate our purposes to other people.

技术经理 Technical Manager

技术经理的一个明显能力体现在对疑难杂症的解决上，他能根据前端页面展现形式，问题出现的模式（出现时间，频率，位置等），服务器日志，造成的错误等逐步缩小错误范围并最终定位错误所在，如果直觉足够好，甚至能精准地一次性定位问题。他的另一个能力在于知道在哪里使用最恰当的技术，这将给项目管理带来益处。作为一名技术经理，他不可避免地需要对下属的技术能力有准确的了解，从而适当地安排工作并设立测试、审核环节，以防止产出糟糕的代码。
A remarkable ability a technical manager should have is how he/she troubleshoots an application. Based on the information from front-end page, the pattern a problem occurs(timing, frequency, position, etc.) Another ability could be he/she knows where to apply a technique in the most appropriate way, this would bring many benefits to project management. As a manager, he/she inevitably has to be well acquainted with each subordinate, subsequently could arrange tasks more precisely, set test or review operations, prevent from outputting unqualified codes.

项目经理 Project Manager

在中国大陆，很多软件开发公司或部门的技术经理和项目经理是同一个人，这里当然有成本的考量，但更多时候是想当然而为之。诚然，优秀的人才当然可以身兼数职，但对于相当复杂（频繁的需求变更，高人员流失率，开发人员的技术水平参差不齐，复杂的业务逻辑）的系统而言，将两者分开很可能是更好的选择。项目经理可以专注于项目的跟踪和推进，与其他部门的连接，等等。
In mainland China, the technical manager and project manager are de facto the same person in many software companies or departments. Of course, the cost could be a major concern, but under many circumstances, it is due to a misunderstanding of software development. Admittedly, a talented personnel can have multiple job duties, but as for a considerably complex system, such as continuous requirements change, high staff turnover, different levels of developers' ability or complicated business logic, it would be better to separate into two distinct roles. As such, a project manager can focus on tracing and pushing a project, connecting with other departments, etc.

架构师 Architect

谁可以成为一名架构师？他必须具备怎样的技能？《一名软件架构师的角色，技能和职责》中对架构师这个岗位进行了详细的描述。
Who is eligible for an architect? Which skills should he/she grasp? The article "The role, skills, and duties of a software architect" elaborated on this subject.

在我看来，架构除了应用到技术上，还可以应用到个人、业务及各种关系上。对于个人而言，其技术的掌握程度，经验的丰富程度，对新技术的热情，知识面的广度与深度，及最重要的，对待“学习”的认知都成为其“架构”的一部分；就业务而言，包括业务功能是否设计的足够清晰（避免歧义）与合理，业务的激励机制的合理性，有没有把人安排到他最适合（擅长）的位置，这些都是“架构”的用武之地。
In my opinion, not only can architecture apply to technology, but to an individual employee, business logic, etc. For an employee, the comprehension of his techniques, his relative experience, enthusiasm for new technology, breadth and depth of knowledge, and the most important part, the cognition to "learning" make up the whole notion of "architecture"; as for business logic, including whether business functions are clear enough(to avoid ambiguity) and reasonable, the rationality of incentive mechanism, is it proper to assign a task to an employee, in all these fields we could apply "architecture".

以下重点讲技术架构。I would like to share more about technology architecture.

技术架构的目标 The purpose of technology architecture

从技术的角度看，要达到某个目标，其衡量标准可以从 3 abilities 进行； From the perspective of technology, we could measure an architecture with such 3 abilities to see if it could reach a goal;
进而，可以通过所使用的技术（框架）对 abilities 的支持程度判断其优劣与适用性； Furthermore, we could determine a technology(framework)'s pros and cons or applicability by how it supports the 3 abilities;
再进而，工程师对具体技术的掌握程度来安排岗位。Lastly, assign the most appropriate post to a software engineer according to his/her specific skills.

以上只是一个思路，而衡量一个系统的架构的优劣还有其他方面，比如这个图：
The above are only a few thoughts, there are many other aspects to consider when we are measuring a system's good and bad parts in terms of the architecture, like this mindmap:

所以，要评估一个技术的架构是否良好，只要这 7 个方面表现良好了，架构就是良好的。
Therefore, to estimate if the architecture of a system is good or not, I believe that as long as such 7 aspects are good, it is good.

技术与业务的冲突 Conflicts between technology and business

(to be added)

CTO

刻意忽略了一些工作，比如市场，技术前瞻性，与其他公司的关联，等等。
Some duties are ignored deliberately, relating to market, tech vista, connection with other companies, etc.

Title: 工作职责(duties)
人(employees)->事(tasks): 优于(prior to)
Note over 人(employees): 招人，裁人(recruit, lay off)；\n鼓励人，安抚人(build teams)
Note over 人(employees): 结构上可替换\n(make replaceable)
事(tasks)->技术(tech): 优于(prior to)
Note left of 人(employees): 工作职责分对内和对外两部分，在对外事务中，\n“事”-“技术”-“金钱”的优先级别需要调整\n(priority adjustment on tasks,\ntech and money when \ndealing with outside events)
Note over 事(tasks): 设置产品或项目的优先级\n(set priorities for products, projects)
技术(tech)->金钱(money): 优于(prior to)
Note over 金钱(money): 合理花费(reasonable expense) > \n节约或过度花费(save or squander)
Note over 技术(tech): 做产品而非做项目；\n文档一致性；开源贡献\n(do projects like a product;\ndoc sync; Open Source Contribution)
Note over 人(employees),金钱(money): 部门协调，项目\n(depts coordination, \nprojects accomplishment)

微服务模块架构图

小猫先生 — Fri, 03 Nov 2017 09:06:32 +0000

Eureka 原理

配置文档

Eureka 架构图

网关

ZUUL

路由配置
Netflix 使用 Zuul 做如下事情：

认证鉴权
审查
压力测试
金丝雀测试
动态路由
服务迁移
负载剪裁
安全
静态应答处理

配置中心 Config

介绍：聊聊 Spring Cloud Config
Spring Cloud Config 项目
-提供服务端和客户端支持
-集中式管理分布式环境下的应用配置
-基于 Spring 环境，无缝与 Spring 应用集成
-可用于任何语言开发的程序
-默认实现基于 git 仓库，可以进行版本管理
-可替换自定义实现
Spring Cloud Config Server 作为配置中心服务端
-拉取配置时更新 git 仓库副本，保证是最新结果
-支持数据结构丰富，yml, json, properties 等
-配合 eureke 可实现服务发现，配合 cloud bus 可实现配置推送更新
-配置存储基于 git 仓库，可进行版本管理
-简单可靠，有丰富的配套方案
访问方式

/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{profile}.properties
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties
/{label}/{application}-{profile}.yml
/{label}/{application}

如何管理下图中的各种配置？
解决方案
架构图

Ribbon

client side load balancer，配置文档

Feign

declarative REST client

Hystrix 断路器 / 熔断器原理

配置文档 Turbine Turbine 配置1.x

分布式服务跟踪系统示意图

（来源：分布式服务跟踪及 Spring Cloud 的实现）

数据收集 Zipkin

Sleuth

Sleuth: distributed tracing via logs，使用 Sleuth 追踪微服务
Zipkin: distributed tracing system with request visualization

数据流转

Trace + Span

ELK 技术栈

ELK stack interaction with different applications based on Log file

Stream 架构图

配置与开发文档

微服务的反模式和陷阱

小猫先生 — Tue, 24 Oct 2017 08:15:39 +0000

第一部分

1、数据驱动的迁移反模式

太多的数据迁移
功能分割优先，数据迁移最后

2、超时反模式

使用超时
使用断路器模式

3、共享反模式

过多依赖
共享代码的技术

4. 到达报告反模式

微服务报告的问题
Asynchronous Event Pushing

5、沙粒陷阱

分析服务的范围和功能
分析数据库事务
分析服务编排

第二部分

6、无因的开发者陷阱

做出错误的决定
了解业务驱动

7、随大流陷阱

微服务的优点和缺点
其他架构模型

8、其它架构模式

header 版本控制
Schema 版本控制

第三部分

9、静态契约陷阱

延迟测量
通信协议比较

10、通信协议使用的陷阱

异步请求
广播能力
事务请求

11、REST 陷阱

分布式事务

小猫先生 — Thu, 19 Oct 2017 06:41:36 +0000

eBay 的 Dan Pritchard 提出的 BASE 原则与传统数据库的 ACID 意思不同。在不同事件发生时，业务状态可能在短时间内与事件结果不一致。

BASE 原则

基本可用 Basically Available
软状态 Soft state
最终一致 Eventually consistent

CP vs AP

强一致
弱一致/最终一致
本地事务 + 异步消息 + 重试 + 幂等 => 最终一致性

ByteTCC 框架

支持 Spring 容器的声明式事务管理
支持普通事务、TCC 事务、业务补偿型事务等事务机制
支持多数据源、跨应用、跨服务器等分布式事务场景
支持长事务
支持 dubbo 服务框架
支持 spring cloud
提供框架层面的幂等性解决方案

事件+消息

（来源：这里）

参考

了解微服务

小猫先生 — Thu, 19 Oct 2017 06:27:47 +0000

大话 Spring Cloud

Spring Cloud 下的工程

Spring Cloud 各组件超时总结
Spring Cloud 各组件重试总结
Spring Cloud Feign:

feign client 的 retry 及超时设置：feign client 默认的 connectTimeout 为 10s，readTimeout 为 60. 单纯设置 timeout，可能没法立马见效，因为默认的 retry 为 5 次. 因此，如果期望 fail fast 的话，需要同时自定义 timeout 以及 retry 的参数，而且要确保反向代理，比如 nginx 的 proxy_connect_timeout 以及 proxy_read_timeout 要大于 feign 的配置才能见效，不然对外部用户感知到的还是 nginx 的 504 Gateway Time-out，起不到 fallback 的效果。
超时配置
 常见问题：
1，FeignClient 接口，不能使用@GettingMapping 之类的组合注解；
2，FeignClient 接口中，如果使用到@PathVariable ，必须指定其 value；
3，解决 Feign/Ribbon 第一次请求失败
Spring Cloud Config：依靠 git 仓库实现的中心化配置管理。配置资源可以映射到 Spring 的不同开发环境中，但是也可以使用在非 Spring 应用中。
Spring Cloud Netflix：不同的 Netflix OSS 组件的集合：Eureka、Hystrix、Zuul、Archaius 等。
Spring Cloud Bus：事件总线，利用分布式消息将多个服务连接起来。非常适合在集群中传播状态的改变事件（例如：配置变更事件）
Spring Cloud Consul：服务发现和配置管理，由 Hashicorp 团队开发。

Spring Cloud Netflix

服务发现：Eureka-server 实例作为服务提供者，可以注册到服务注册中心，Eureka 客户端可以通过 Spring 管理的 bean 发现实例；
断路器：利用注解，可以创建一个简单的 Hystrix 客户端；通过 Java 配置文件可以创建内嵌的 Hystrix 控制面板；
声明式 REST 客户端：使用 Feign 可以创建声明式、模板化的 HTTP 客户端；
客户端负载均衡器：Ribbon
路由器和过滤器：Zuul 可以在微服务架构中提供路由功能、身份验证、服务迁移、金丝雀发布等功能，详见模块架构图 ZUUL。

Dubbo vs Spring Cloud

微服务环境层级

九大特性

——来自 Martin Fowler 的 Microservices

服务组件化
按业务组织团队
做“产品”的态度
智能端点与哑管道
去中心化治理
去中心化管理数据
基础设施自动化
容错设计
演进式设计

怎样使一个微服务 “产品就绪”

——来自 Susan Fowler-Rigetti 原文不详，引自：实现微服务，每个组织都会面临的 6 个挑战

稳定性和可靠性

使用微服务，会带来更多的变更和更快的部署，这就导致了不稳定性。她称，一个可靠的微服务应该是能够被其客户、依赖和生态所信任的。她认为稳定性和可靠性是息息相关的，大多数稳定性需求会伴随可靠性需求。一条在进入生产环境前具备多个阶段的部署流水线就是一个很好的例子。

可扩展性和性能

大多数人认为他们能够通过微服务无偿获得可扩展性，但这对于巨大的规模而言并非如此。随着流量的增加，它们应该得到适当的扩展。

许多语言在设计上就无法做到高效的扩展，因为它们无法做到并发、分区和高效。这使得用那些语言开发的微服务难以得到合理的扩展。Fowler-Rigetti 谢绝指出具体的语言，但她说，“我很肯定自己能想到一些。”
她解释道，可扩展性是指微服务能够处理多少请求 (译者：可扩展性是指系统为应对业务增加而对自身进行相应扩展的能力，有些时候也作伸缩性，即在业务缩减的时候，系统规模做相应的收缩)，性能则是指服务能够多好地处理这些任务 (译者：这应该叫 QoS)。一个高性能的服务应该合理地使用资源、高效地处理任务、快速地处理请求。

如果微服务无法得到预期的扩展，那么其出现故障的概率会急剧上升。延迟的增长会导致低下的可用性。

容错和灾备

为了保证可用性这个终极目标，开发者需要确保任何微服务出现故障后均不会导致系统宕掉。因此开发者需要知道所有的故障模式，并且做好备份工作，以应对故障的发生。

成功灾备的关键是健壮的弹性测试，它包括代码测试、负载测试，以及含其它主动性测试的混沌测试。每个故障模式都应该在生产环境中复现，以观察能否 “存活”。

给定微服务环境的复杂度和复杂的依赖链，故障是难以避免的（译者：总觉得这句话本来就有问题）。微服务必须能够承受来自内部和外部的故障。

监控和文档

Fowler-Rigetti 说，“我发现在微服务架构中，系统的状态永远和上一秒不同。如果你不知晓系统的状态，在系统故障时你将无法得知，这会导致最终的失败。”

拥有一款好的监控工具来展示系统在任意时刻的状态，这是很关键的。缺少良好的监控工具是造成服务中断的第二大原因。

日志是监控的本质部分，因为你将几乎不可能复现 bug。知晓发生了什么的唯一方式就是确保你在那时记录了系统的状态。唯一的手段便是合理的日志记录。这使得我们能够轻松信任服务。

文档对于每个开发者而言都是阻碍，但它确实是关键的。它移除了技术债务，并使得团队新成员能够赶上进度。

微服务和演进式架构

初识 Spring Cloud 和微服务

小猫先生 — Thu, 12 Oct 2017 04:17:56 +0000

Spring Cloud 在国内中小型公司能用起来吗？

大话 Spring Cloud

Spring Cloud 下的工程

Spring Cloud Config：依靠 git 仓库实现的中心化配置管理。配置资源可以映射到 Spring 的不同开发环境中，但是也可以使用在非 Spring 应用中。
Spring Cloud Netflix：不同的 Netflix OSS 组件的集合：Eureka、Hystrix、Zuul、Archaius 等。
Spring Cloud Bus：事件总线，利用分布式消息将多个服务连接起来。非常适合在集群中传播状态的改变事件（例如：配置变更事件）
Spring Cloud Consul：服务发现和配置管理，由 Hashicorp 团队开发。

Spring Cloud Netflix

服务发现：Eureka-server 实例作为服务提供者，可以注册到服务注册中心，Eureka 客户端可以通过 Spring 管理的 bean 发现实例；
断路器：利用注解，可以创建一个简单的 Hystrix 客户端；通过 Java 配置文件可以创建内嵌的 Hystrix 控制面板；
声明式 REST 客户端：使用 Feign 可以创建声明式、模板化的 HTTP 客户端；
客户端负载均衡器：Ribbon
路由器和过滤器：Zuul 可以在微服务架构中提供路由功能、身份验证、服务迁移、金丝雀发布等功能，详见模块架构图 ZUUL。

Dubbo vs Spring Cloud

微服务环境层级

九大特性

—— 来自 Martin Fowler 的 Microservices

服务组件化
按业务组织团队
做 “产品” 的态度
智能端点与哑管道
去中心化治理
去中心化管理数据
基础设施自动化
容错设计
演进式设计

怎样使一个微服务 “产品就绪”

—— 来自 Susan Fowler-Rigetti 原文不详，引自：实现微服务，每个组织都会面临的 6 个挑战

稳定性和可靠性使用微服务，会带来更多的变更和更快的部署，这就导致了不稳定性。她称，一个可靠的微服务应该是能够被其客户、依赖和生态所信任的。她认为稳定性和可靠性是息息相关的，大多数稳定性需求会伴随可靠性需求。一条在进入生产环境前具备多个阶段的部署流水线就是一个很好的例子。
可扩展性和性能大多数人认为他们能够通过微服务无偿获得可扩展性，但这对于巨大的规模而言并非如此。随着流量的增加，它们应该得到适当的扩展。许多语言在设计上就无法做到高效的扩展，因为它们无法做到并发、分区和高效。这使得用那些语言开发的微服务难以得到合理的扩展。Fowler-Rigetti 谢绝指出具体的语言，但她说，“我很肯定自己能想到一些。” 她解释道，可扩展性是指微服务能够处理多少请求 (译者：可扩展性是指系统为应对业务增加而对自身进行相应扩展的能力，有些时候也作伸缩性，即在业务缩减的时候，系统规模做相应的收缩)，性能则是指服务能够多好地处理这些任务 (译者：这应该叫 QoS)。一个高性能的服务应该合理地使用资源、高效地处理任务、快速地处理请求。如果微服务无法得到预期的扩展，那么其出现故障的概率会急剧上升。延迟的增长会导致低下的可用性。
容错和灾备为了保证可用性这个终极目标，开发者需要确保任何微服务出现故障后均不会导致系统宕掉。因此开发者需要知道所有的故障模式，并且做好备份工作，以应对故障的发生。成功灾备的关键是健壮的弹性测试，它包括代码测试、负载测试，以及含其它主动性测试的混沌测试。每个故障模式都应该在生产环境中复现，以观察能否 “存活”。给定微服务环境的复杂度和复杂的依赖链，故障是难以避免的（译者：总觉得这句话本来就有问题）。微服务必须能够承受来自内部和外部的故障。
监控和文档 Fowler-Rigetti 说，“我发现在微服务架构中，系统的状态永远和上一秒不同。如果你不知晓系统的状态，在系统故障时你将无法得知，这会导致最终的失败。” 拥有一款好的监控工具来展示系统在任意时刻的状态，这是很关键的。缺少良好的监控工具是造成服务中断的第二大原因。日志是监控的本质部分，因为你将几乎不可能复现 bug。知晓发生了什么的唯一方式就是确保你在那时记录了系统的状态。唯一的手段便是合理的日志记录。这使得我们能够轻松信任服务。文档对于每个开发者而言都是阻碍，但它确实是关键的。它移除了技术债务，并使得团队新成员能够赶上进度。

微服务和演进式架构

Java 小工具

小猫先生 — Thu, 12 Oct 2017 03:52:47 +0000

JMH

Another tutorial: JMH - Java Microbenchmark Harness see: Java Samples
JMH 是一个由 OpenJDK/Oracle 里面那群开发了 Java 编译器的大牛们所开发的 Micro Benchmark Framework 。何谓 Micro Benchmark 呢？简单地说就是在 method 层面上的 benchmark，精度可以精确到微秒级。可以看出 JMH 主要使用在当你已经找出了热点函数，而需要对热点函数进行进一步的优化时，就可以使用 JMH 对优化的效果进行定量的分析。

比较典型的使用场景还有：

想定量地知道某个函数需要执行多长时间，以及执行时间和输入 n 的相关性
一个函数有两种不同实现（例如实现 A 使用了 FixedThreadPool，实现 B 使用了 ForkJoinPool），不知道哪种实现性能更好

logback 配置解析

如何引入日志？
日志输出格式以及输出方式如何配置？
代码中如何使用？

Validation

@NotNull //不允许为空
@Size //长度或大小范围

@Size(min = 1, max = 20) private String name;
@NotNull(groups = ValidationService.Save.class) // 保存时不允许为空，更新时允许为空，表示不更新该字段
@Pattern

@Pattern(regexp = "^\\s*\\w+(?:\\.{0,1}[\\w-]+)*@[a-zA-Z0-9]+(?:[-.][a-zA-Z0-9]+)*\\.[a-zA-Z]+\\s*$") private String email;
@Min(18) //最小值
@Max //最大值

@Max(100) private int age;
@Past //必须为一个过去的时间

@Past private Date loginDate;
@Future //必须为一个未来的时间

@Future private Date expiryDate;

Transactional（来源：Spring @Transactional 原理及使用）

事务传播行为
事务隔离级别
- 脏读 : 一个事务读取到另一事务未提交的更新数据
- 不可重复读 : 在同一事务中，多次读取同一数据返回的结果有所不同，换句话说，后续读取可以读到另一事务已提交的更新数据。相反，” 可重复读” 在同一事务中多次读取数据时，能够保证所读数据一样，也就是后续读取不能读到另一事务已提交的更新数据
- 幻读 : 一个事务读到另一个事务已提交的 insert 数据
属性

模块设计(Spring Cloud)

小猫先生 — Tue, 10 Oct 2017 07:04:44 +0000

引自： http://skaka.me/blog/2016/08/10/springcloud3/

一个完整系统的各模块关系示例。每个服务都应当是一个独立的项目, 彼此之间只是通过 pom 引用。

普通目录

docs: 存放文档资料, 例如数据库脚本, astah 文件 (UML 工具) 等.
logs: 运行日志存放目录.

公共模块

apiutils: api 模块公共父模块.
common: 服务模块公共父模块, 存放微服务共同依赖的逻辑, 例如事件处理, 定时任务等.
utils: 工具类模块.

基础服务模块

eureka: eureka 服务. 提供服务注册与服务发现
config: config 服务. 提供配置管理服务
turbine: hystrix 服务监控

服务模块

account: 账户服务.
coupon: 优惠券服务.
order: 订单服务.
product: 产品服务.
user: 用户服务.

其他模块

integration-test: 集成测试模块.

模块内部结构

api: api 接口模块. 其他依赖 user 服务的服务会依赖这个模块.
core: user 服务实现模块.
api 和 core 模块内容都是标准的 maven 项目结构, 其中 core 模块主要有这么一些子目录:
- context: 存放 Spring Boot 启动类.
- dao: DAO 层.
- domain: Model 层. service: Service 层.
- web: 存放 Spring MVC Controller.

架构设计摘录

小猫先生 — Tue, 10 Oct 2017 06:57:36 +0000

REST

REST 接口一般更适合用来实现查询或其他不需要事务的操作。而涉及到数据修改，往往通过事件来完成。

服务拆分与架构演进

如何拆？即如何正确理解业务，将单体结构拆分为服务化架构？
拆完后业务变了增加了怎么办？即在业务需求不断发展变化的前提下，如何持续快速地演进？
如何安全地持续地拆？即如何在不影响当下系统运行状态的前提下，持续安全地演进？
如何保证拆对了？
拆完了怎么保证不被破坏？

命令查询职责分离 (CQRS) 模式

假如你对 CRUD 模式带出的问题感到疑惑与烦恼，推荐你阅读这篇文字。当然，本文讲了更多东西，不仅仅只是为了解决 CRUD 相关的问题。

使用同一个对象实体来进行数据库读写可能会太粗糙，大多数情况下，比如编辑的时候可能只需要更新个别字段，但是却需要将整个对象都穿进去，有些字段其实是不需要更新的。在查询的时候在表现层可能只需要个别字段，但是需要查询和返回整个实体对象。
使用同一实体对象对同一数据进行读写操作的时候，可能会遇到资源竞争的情况，经常要处理的锁的问题，在写入数据的时候，需要加锁。读取数据的时候需要判断是否允许脏读。这样使得系统的逻辑性和复杂性增加，并且会对系统吞吐量的增长会产生影响。
同步的，直接与数据库进行交互在大数据量同时访问的情况下可能会影响性能和响应性，并且可能会产生性能瓶颈。
由于同一实体对象都会在读写操作中用到，所以对于安全和权限的管理会变得比较复杂。

你需要知道的那些 Abilities

小猫先生 — Tue, 10 Oct 2017 06:01:47 +0000

引自：http://xianjing.github.io/2017/08/11/abilities/

如果你去买一部手机，你会考虑什么因素呢？一般我们都会首先考虑智能手机、照相功能、多大容量等。而除了这些，我们通常还会考虑品牌、颜色、外型好不好看、时尚与否。作为一个软件产品也不例外，用户首先会期望系统要满足正常的功能需求，同时系统还要满足好用、性能好、稳定可靠等其他特性。一般我们会把这些称为非功能性需求或者跨功能性需求。系统的每一次故障和宕机对用户都是不可忽视的损失，所以这些非功能性需求也是软件质量非常重要的属性，是软件架构设计需要满足的目标。

在运行时的非功能需求中，我们常常会提到几个词有 Availability、Stability 和 Reliability，即系统要高可用、高可靠和稳定。那么可用、可靠还有稳定是什么意思呢？如何衡量？它们之间又有什么区别？我经常在不同场景下听到这几个词的混用。今天就先来谈一谈这几个 ability。

1. Availability 可用性

Availability defines the proportion of time that the system is functional and working. It can be measured as a percentage of the total system downtime over a predefined period. Availability will be affected by system errors, infrastructure problems, malicious attacks, and system load. - Microsoft Application Architecture Guide

可用性指系统在给定时间内可以正常工作的概率，通常用 SLA 指标来表示，如下图所示。
SLA指标

墨菲定律说 “会出错的事总会出错”，可用性做到 100 是可望而不可及的。对于 SLA 指标来说，9 的数字越多可用性越高，宕机时间越少，系统就可以在给定的时刻内高比例地正常工作。然而对系统的挑战就越大，投入的成本也会越高。比如 5 个 9 要求系统每年只宕机 5 分钟左右，而 4 个 9 要求每年宕机时间不超过一个小时。这就使得系统需要在设计、基础设施、数据备份等不同层面采取多种方式，甚至增加基础设施投资来保证可用性。

“当你的设备处理人命关天的事情，或业务中断一分钟就会损失百万美刀，那么你可以考虑 99.99% 的可靠性。” Robertson（Linux 高可用项目开发者）

不同系统的可用性要求也是不同的，比如：淘宝、京东等这些电商系统用户量很多，不同区不同时刻都有大量的用户在使用系统，这必然对系统的可用性要求很高。据以往这些系统的故障统计和不准确地测试数据推测，它们目前的可用性是在 3 个 9 到 4 个 9 左右。相对而言，企业类的工作软件因为通常只在工作时间被使用，或只在某些特定的地区使用，或只给某部分人某一特定时间使用，可用性的需求就会低一些。典型的系统就数 salesforce 了，经常会看到 “周末又要升级了” 的提示。

影响可用性的因素有很多，包括系统故障、基础设施故障、数据故障、安全攻击、系统压力等等。

2. Reliability 可靠性

Reliability is a measure of the probability that an item will perform its intended function for a specified interval under stated conditions.

可靠性是在给定的时间间隔和给定条件下，系统可以无故障持续运行的概率。那么可靠性和可用性有什么区别呢？在《分布式系统原理与范型》中提到的下面例子中比较准确的解释了两者的区别：

如果系统在每小时崩溃 1ms，那么它的可用性就超过 99.9999%，但是它还是高度不可靠。与之类似，如果一个系统从来不崩溃，但是每年要停机两星期，那么它是高度可靠的，但是可用性只有 96%。

简而言之，可用性关注的是系统任何时刻可以持续正常工作的能力，关注的是服务总体的持续时间。系统在给定时间内总体的运行时间越长，可用性越高。而可靠性更关注系统可以无故障地持续运行的概率，关注的是故障率。故障的频率越高，可靠性越低。可靠性差一定程度上是会影响可用性的，但反过来不一定成立。

这里面还有一些常用的指标来衡量可用性和可靠性：

MTBF（Mean Time Between Failure）即平均无故障时间，是指从新的产品在规定的工作环境条件下开始工作到出现第一个故障的时间的平均值。MTBF 越长表示可靠性越高，正确工作能力越强。
MTTR（Mean Time To Repair）即平均修复时间。是指可修复产品的平均修复时间，就是从出现故障到修复中间的这段时间。MTTR 越短表示易恢复性越好。
MTTF（Mean Time To Failure）即平均失效时间。系统平均能够正常运行多长时间，才发生一次故障。系统的可靠性越高，平均无故障时间越长。

基于以上指标，可用性可以如此计算：

Availability = UpTime/(UpTime+DownTime) = MTBF / (MTBF + MTTR)

作为系统的响应，首要目标是先降低故障的次数，频率要低，从而提高可靠性；同时在故障出现后，要提高故障的恢复时间，速度要快，从而提高业务的可用性。

影响可靠性的因素就是能够引起故障的所有因素，包括软件设计错误，编码错误，硬件故障等等。

3. Stability 稳定性

Stability is about how many failures an application exhibits; whether that is manifested as unexpected or unintended behaviour, users receiving errors, or a catastrophic failure that brings a system down. The fewer failures that are observed the more stable an application is.

软件的稳定性，指软件在一个运行周期内、在一定的压力条件下，在持续操作时间内出错的概率，性能劣化趋势等等。如果一个系统的故障率很高，它一定是高度不可靠的，也一定是不稳定的。那么如何区分稳定性和可靠性呢？

对于电力系统而言，稳定性就是 “人民用电不要忽明忽暗忽快忽慢”，可靠性就是” 不要用着用着突然没有啦 “。- 知乎盛夏白日梦

如果一个系统的性能时好时坏，它一定是不稳定的，而不一定是不可靠的。稳定性更关注系统在给定条件下的响应是否一致，行为是否稳定。可靠是可用的前提，稳定是可靠的进一步提升。

今天在 Stackoverflow 看到这样一段代码来表示这两个的区别，甚为有趣：

Reliable but unstable:
  add(a,b):
    if randomInt mod 5 == 0: 
      throw exception
    else
      print a+b        
Stable but unreliable:
  add(a,b):
    if randomInt mod 5 == 0: 
      print a+a
    else
      print a+b

不知道写到这里，你是否对可用性、可靠性和稳定性有了更清晰的了解了呢？有了这些指标可以帮助我们去分析系统存在的问题，比如说故障频率较高，故障恢复时间较长，那么系统的可靠性可用性一定很低，对用户的影响一定很高，就可以促使我们去从各个角度去改进和提高，去找架构设计的问题，去找系统实现的缺陷，去找依赖的基础设施问题等等，从而改善我们的系统。尤其是在当下复杂的分布式系统下，这些显得尤为重要。

那么，最后请问我们常见的容错处理、蓝绿部署、回滚、cluster、灾备会有助于提高以上哪个 ability 呢？

学习幂等性 Learning Idempotence

小猫先生 — Mon, 09 Oct 2017 06:53:08 +0000

程序设计方法及模式

小猫先生 — Mon, 09 Oct 2017 06:46:57 +0000