Java开发6年了，javaweb开发实战宝典pdf

程序员：给多少工资，干多少事

我们不是经常会看到一个关于西游记的“悖论”吗：

为什么孙悟空初期大闹天宫的时候那么厉害？因为他自己当老板，打一群天庭的打工仔。

为什么取经路上又变得不行了？作为一个打工仔，去跟一群出来自己创业的妖怪打架。

很多程序员想跟老板说，但又不太敢说，实际却在做的一件事。

事实却是：

“拿着10K的工资，做着20K的事，还要操着30K的心！”

其实，这些情况都不奇怪，甚至是人之常情。

微服务是什么

微服务起源于2005年Peter Rodgers博士在云端运算博览会提出的微Web服务(Micro-Web-Service)，根本思想类似于Unix的管道设计理念。2014年，由Martin Fowler 与 James Lewis共同提出了微服务的概念，定义了微服务架构风格是一种通过一套小型服务来开发单个应用的方法，每个服务运行在自己的进程中，并通过轻量级的机制进行通讯（HTTP API）。关键的三点是small、automated以及lightweight。

对比SOA，微服务可以看做是SOA的子集，是轻量级的SOA，粒度更细的服务，独立进程、数据分离，更注重敏捷、持续交付、DevOps以及去中心化实践。其共同的架构原理：

• 单一职责

• 关注分离：

  控制与逻辑相分离

• 模块化和分而治之

特点：

• 用服务进行组件化

• 围绕业务能力进行组织

• 是产品而非项目

• 端点智能化和哑管道: 控制逻辑都在端点，管道仅仅是传输

• 全自动化部署

• 语言和数据的去中心化控制

• 面向失败设计

• 渐进式设计

综合来看，其优缺点如下：

优点：

• 模块的强边界

• 独立部署

• 技术选型的多样性

缺点：

• 分布式带来编程复杂度，远程调用的消耗

• 舍弃强一致性，实现最终一致性

• 操作复杂性要求有一个成熟的运维团队或者运维基础设施

为什么要采用微服务

是否选择微服务取决于你要设计的系统的复杂度。微服务是用来把控复杂系统的，但是随之而来的就是引入了微服务本身的复杂度。需要解决包括自动化部署、监控、容错处理、最终一致性等其他分布式系统面临的问题。即使已经有一些普遍使用的解决方案，但是仍然是有不小的成本的。

生产力和复杂度的关系如图所示，可见系统越复杂，微服务带来的收益越大。此外，无论是单体应用还是微服务，团队的技能都需要能够把控住。

马丁.福勒的一个观点是：除非管理单体应用的成本已经太复杂了（太大导致很难修改和部署），否则都不要考虑微服务。大部分应用都应该选择单体架构，做好单体应用的模块化而不是拆分成服务。

因此，系统一开始采用单体架构，做好模块化，之后随着系统变得越来越复杂、模块/服务间的边界越来越清晰，再重构为微服务架构是一个合理的架构演化路径。

四个可以考虑上微服务的情况：

1. 多人开发一个模块/项目，提交代码频繁出现大量冲突。

2. 模块间严重耦合，互相依赖，每次变动需要牵扯多个团队，单次上线需求太多，风险大。

3. 主要业务和次要业务耦合，横向扩展流程复杂。

4. 熔断降级全靠if-else。

微服务的三个阶段：