软件工程发展

软件工程发展 5.png 6.png 应用架构演进历史.png

大师级人物Martin Fowler在他谈论微服务的个人主页上提到，微服务并没有一个非常明确的定义。事实上有很多种分布式系统的实现都可以被看成（或者说勉强看成）是面向微服务架构的。

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务于服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

软件架构的进化

所有的应用全都是混合在一起的 形成了如JDBC等独立组件 多层的模式 仍然是一单体模式的形式存在 单体模式的优势 单体模式的不足 微服务架构 重新设计一下开始所提到的传统应用

微服务架构的特性

单一职责

微服务架构中的每个服务，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单元，不同的服务通过“管道”的方式灵活组合，从而构建出庞大的系统。

轻量级通信

服务之间通过轻量级的通信机制实现互通互联，而所谓的轻量级，通常指语言无关、平台无关的交互方式。

对于轻量级通信的格式而言，我们熟悉的 XML 和 JSON，它们是语言无关、平台无关的；对于通信的协议而言，通常基于** HTTP**，能让服务间的通信变得标准化、无状态化。目前大家熟悉的 REST（Representational State Transfer）是实现服务间互相协作的轻量级通信机制之一。使用轻量级通信机制，可以让团队选择更适合的语言、工具或者平台来开发服务本身。

独立性

915691-20161202204533990-344195559.png

每个服务在应用交付过程中，独立地开发、测试和部署。
在单块架构中所有功能都在同一个代码库，功能的开发不具有独立性；当不同小组完成多个功能后，需要经过集成和回归测试，测试过程也不具有独立性；当测试完成后，应用被构建成一个包，如果某个功能存在 bug，将导致整个部署失败或者回滚。
在微服务架构中，每个服务都是独立的业务单元，与其他服务高度解耦，只需要改变当前服务本身，就可以完成独立的开发、测试和部署。

敏捷性

915691-20161202205213834-1209934999.png

因为把每一个代码都分到了每一个微小的服务当中，所以，代码的运行速度更快，也带来了更短的反馈周期。
简化了使用方法，因为每一个微服务功能都非常单一，非常的简单，使用起来非常方便。
同时，可以非常快速的应对变化，当发生一个新的需求的时候，可以很快的应对这种需求的变化。

接受新技术

915691-20161202205502209-1808630097.png

因为微服务是分散式的管理方式，开发过程中可能每一个组或者团队只负责自己的服务，
如果需要做一些技术上的调整，只需要在组内得到同意即可。
同时，每一个微服务可以使用自己独立的技术，只需要保持对其他服务提供API的接口不变就可以。
这样的架构使之非常易于接受新事物，使重构服务变的可行。

高效的团队

915691-20161202205907631-1291425391.png

每一个团队只需要负责自己的功能模块，责任明晰，边界清楚。
如果团队发生重组的时候，可以围绕业务功能进行组织，非常灵活。

进程隔离

单块架构中，整个系统运行在同一个进程中，当应用进行部署时，必须停掉当前正在运行的应用，部署完成后再重启进程，无法做到独立部署。
有时候我们会将重复的代码抽取出来封装成组件，在单块架构中，组件通常的形态叫做共享库（如 jar 包或者 DLL），但是当程序运行时，所有组件最终也会被加载到同一进程中运行。
在微服务架构中，应用程序由多个服务组成，每个服务都是高度自治的独立业务实体，可以运行在独立的进程中，不同的服务能非常容易地部署到不同的主机上。

SOA与 微服务

序号	SOA实现	微服务架构实现
1	企业级，自顶向下开展实施	团队级，自底向上开展实施
2	服务由多个子系统组成，粒度大	一个系统被拆分成多个服务，粒度细
3	企业服务总线，集中式的服务架构	无集中式总线，松散的服务架构
4	集成方式复杂（ESB/WS/SOAP）	集成方式简单（HTTP/REST/JSON）
5	单块架构系统，相互依赖，部署复杂	服务能独立部署

单块架构

对不同层的代码而言，经过编译、打包和部署后，所有的代码最终还是运行在同一个进程中。而这，就是所谓的单块架构。

单块架构的优缺点

1004011.png

优点：

• 易于开发： 开发方式简单，IDE 支持好，方便运行和调试。
• 易于测试： 所有功能运行在一个进程中，一旦进程启动，便可以进行系统测试。
• 易于部署： 只需要将打好的一个软件包发布到服务器即可。
• 易于水平伸缩： 只需要创建一个服务器节点，配置好运行时环境，再将软件包发布到新服务器节点即可运行程序（当然也需要采取分发策略保证请求能有效地分发到新节点）。

缺点：

915691-20161202210119506-1645806815.png

• 维护成本大： 当应用程序的功能越来越多、团队越来越大时，沟通成本、管理成本显著增加。当出现 bug 时，可能引起 bug 的原因组合越来越多，导致分析、定位和修复的成本增加；并且在对全局功能缺乏深度理解的情况下，容易在修复 bug 时引入新的 bug。
• 持续交付周期长： 构建和部署时间会随着功能的增多而增加，任何细微的修改都会触发部署流水线。
• 新人培养周期长： 新成员了解背景、熟悉业务和配置环境的时间越来越长。
• 技术选型成本高： 单块架构倾向于采用统一的技术平台或方案来解决所有问题，如果后续想引入新的技术或框架，成本和风险都很大。
• 可扩展性差： 随着功能的增加，垂直扩展的成本将会越来越大；而对于水平扩展而言，因为所有代码都运行在同一个进程，没办法做到针对应用程序的部分功能做独立的扩展。

理想中的微服务架构

没有什么东西是完美的，网站架构也是这样的，只有「比之前好一点」的架构或「目前最好的实现方式」，不存在理想中的架构，那么理想中微服务架构应该是怎么样的呢，我觉得至少应该有如下几个特点：

• 能支持当前业务需求，当然这只是最最基本的条件；
• 每个微服务都要去中心化，不存在单点故障；
• 每个微服务都要实现高可用、高负载，不会因为一个服务不可用而影响了整套业务流；
• 每个微服务都要高度通用化，即多种终端都可调用，不分语言和平台；
• 服务部署或升级简单，不会消耗大量人力并且部署过程不易出现人为错误；
• 微服务具有快速注册与自动发现功能（例如dubbo框架）

当然，这只是其中能想到的几点，实际环境中用到的微服务框架有可能会根据实际业务需求优化出更加个性化的功能，也可能有些功能是不需要的。还是那句话，架构是服务于业务的，能快速方便的满足业务需求的架构才是好的架构，才是好的微服务架构。

以上只是个人理解，将自己的理解写出，以备自己查看。

也许我说的并一定对，也许我说的全是错的。