共计 2592 个字符，预计需要花费 7 分钟才能阅读完成。
整体倒退概览
服务架构始终处于演变之中，为了适宜本人的业务，一直的去调整。
整体的倒退历程如下：
开发者视角
从一个 java 开发者，感触大略经验了上面几个历程：
第一阶段：单体架构
晚期，大部分 IT 零碎都是单体零碎，例如传统的 SSH 架构，此时前后端也没有拆散，UI 组件也蕴含在了管制层：
这个也就是老马刚毕业时候的架构，SSH 根本是面试必问。
不过当初这些都产生了一些变动，支流曾经变成了 spring mvc + spring contaienr + mybatis。
只能说，spring，java 界永远的春天！
第二阶段：分布式架构
为了不便给零碎扩容，以及减少零碎的复用性，呈现分布式系统。
另一方面，零碎模块疾速收缩，为了升高零碎外部的复杂度，于是对系统模块进行拆解，分不到不同的零碎中，升高模块耦合，放慢迭代速度。
ps: 其实次要是升高单个利用的复杂性，让每一个利用专一于一件事件。这样可保护老本大大降低，换言之，开发完后当前，能够让一个刚毕业的新人做运维。把开发者裁掉，降低成本。
支流次要是 SOA 和 MSA 两种体系。
SOA
晚期的分布式系统是基于面向服务的架构 SOA。
SOA 是微服务的前身，次要是为了解脱单体利用的问题，达到以下成果：
- 充分利用现有的基础设施；
- SOA 体系结构依赖于消息传递（AMQP，MSMQ）和 SOAP 作为次要的近程拜访协定。
- 疾速响应业务变动；
架构图如下：
异构零碎，也能够通过消息中间件的协定转换进行互相调用。
这个我倒是接触过一段时间，过后业务零碎是 C# 开发，我所在的后端服务应用的是 java 技术开发。过后的协定应用的是 webservice。
然而用起来感觉不是很顺畅，次要毛病如下：
（1）WebService 中罕用的 SOAP 通信协议，通常应用 XML 格局进行通信，数据冗余，协定过重
（2）服务治理很不欠缺。
起初逐步演变为了当初的 MSA（Micro-Service Archeticture 微服务架构），从而实现了更加松耦合以及更加灵便的零碎。
MSA
微服务是一种软件开发技术——面向服务的体系结构 (SOA) 体系结构款式的变体，它将应用程序结构为涣散耦合服务的汇合。
在微服务体系结构中，服务是细粒度的，协定是轻量级的。
- 微服务架构图示
长处
微服务架构有很多重要的长处。
首先，它解决了复杂性问题。它将单体利用合成为一组服务。尽管性能总量不变，但应用程序已被合成为可治理的模块或服务。
这些服务定义了明确的 RPC 或音讯驱动的 API 边界。微服务架构强化了利用模块化的程度，而这通过单体代码库很难实现。
因而，微服务开发的速度要快很多，更容易了解和保护。
第三，微服务架构能够使每个微服务独立部署。
最初，微服务架构使得每个服务都可独立扩大。
当初这种架构模式曾经成为支流，集体感触最深的就是如果你只负责繁多服务，你能够把他了解的比拟透彻，而且保护起来也没有那么简单。如果有性能变更，只上线对应的利用即可。
毛病
微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。
- 运维开销及成本增加
- 必须有松软的 DevOps 开发运维一体化技能
- 隐式接口及接口匹配问题
- 代码反复
- 分布式系统的复杂性
- 异步机制
- 可测性的挑战
个人感觉微服务最大的问题在于零碎的拆分之后，很难有一个人能够晓得零碎的全貌，所以定位问题变得非常复杂。
举个例子，如果交易产生一笔失败，你可能要从 API 网关 =》业务零碎 =》交易外围 =》领取外围 =》风控系统问一遍能力晓得起因，最初发现是对底层的零碎返回了一个失败，这里波及到多个零碎的沟通老本，基本上半天的工夫就没了。
SOA vs 微服务
| SOA | 微服务架构 |
|---|---|
| 应用程序服务的可重用性的最大化 | 专一于解耦 |
| 系统性的扭转须要批改整体 | 系统性的扭转是创立一个新的服务 |
| DevOps 和继续交付正在变得风行，但还不是支流 | 强烈关注 DevOps 和继续交付 |
| 专一于业务性能重用 | 更器重“上下文边界”的概念 |
| 通信应用企业服务总线 ESB | 对于通信而言，应用较少精密和简略的音讯零碎 |
| 反对多种音讯协定 | 应用轻量级协定，例如 HTTP，REST 或 Thrift API |
| 对部署到它的所有服务应用通用平台 | 应用程序服务器不是真的被应用，通常应用云平台 |
| 容器（如 Docker）的应用不太受欢迎 | 容器在微服务方面成果很好 |
| SOA 服务共享数据存储 | 每个微服务能够有一个独立的数据存储 |
| 独特的治理和规范 | 轻松的治理，更加关注团队合作和抉择自在 |
挑战
微服务的挑战能够概述如下：
- API Gateway
- 服务间调用
- 服务发现
- 服务容错
- 服务部署
- 数据调用
不过侥幸的是，很多成熟的中间件，曾经为咱们解决了这些问题。
第一代微服务框架
dubbo 的架构
Dubbo 的架构如下：
dubbo 针对 rpc 这部分做的很好，单也仅此而已。
然而为什么还是会这么火爆呢？
很多架构的降级都会有历史包袱，除非你是一家新公司，全新的利用。
大部分的利用都是 spring 或者 springboot 的，所以当初大部分公司都是 springboot + dubbo 的技术选型计划，这样能够让架构的平滑的迁徙。
如果你们公司是全新的技术选型，能够思考 spring cloud。
spring cloud 架构
Spring Cloud 架构如下：
你会发现 spring cloud 能够说是 java 技术栈中，比较完善的微服务框架。
当然，spring 再牛，负责的申明周期也只是 jvm 之内，利用的部署运维也是须要思考的。
每一项技术都有其劣势和局限性，所以须要联合应用。
举荐浏览：
Microservice Architectures With Spring Cloud and Docker
目前 docker 虚拟化技术如日中天，联合 k8s 掌托。
我选称这盛世为，喝不起咖啡的打工人，在春天的货船上，996 搬砖！
下一代微服务：Service Mesh？
Service Mesh 也是目前比拟火爆的技术，咱们后续进行详解。
集体感悟
技术架构的演进和生物的进化是相似的，物竞天择，适者生存。
学习技术也不能只局限于当初这一刻，要学会去回顾技术的历史，晓得为什么是这样？如果有能力，也能够引领技术的将来，为什么不是这样呢？
我感觉本人很侥幸，最后接触的是单体利用，是 spring xml 配置的时代。
我感觉本人很可怜，框架层出不穷，技术突飞猛进，如果不继续学习，不出 5 年，就会被彻底淘汰。
为了不被那么快淘汰，本系列将从微服务的倒退历史，理论知识，入门应用，利用实战，实现原理，反复造轮子等方面，逐步了解微服务。
我是老马，期待与你，一起见证开发者的春天！
