微服务架构（一）

  微服务的概念源于2014年3月Martin Fowler所写的一篇文章“Microservices”(http://martinfowler.com/articles/microservices.html)。

一，为什么需要微服务架构？

1、使用传统的整体式架构(Monolithic Architecture)应用开发系统，如CRM、ERP等大型应用，随着新需求的不断增加，企业更新和修复大型整体式应用变得越来越困难；

2、随着移动互联网的发展，企业被迫将其应用迁移至现代化UI界面架构以便能兼容移动设备，这要求企业能实现应用功能的快速上线；

3、许多企业在SOA投资中得到的回报有限，SOA可以通过标准化服务接口实现能力的重用，但对于快速变化的需求，受到整体式应用的限制，有时候显得力不从心；

4、随着应用云化的日益普及，生于云端的应用具有与传统IT不同的技术基因和开发运维模式。

此外，从技术方面看，云计算及互联网公司大量开源轻量级技术不停涌现并日渐成熟：

5、互联网/内联网/网络更加成熟；

6、轻量级运行时技术的出现(node.js, WAS Liberty等)；

7、新的方法与工具(Agile, DevOps, TDD, CI, XP, Puppet, Chef…)；

8、新的轻量级协议(RESTful API接口, 轻量级消息机制)；

9、简化的基础设施：操作系统虚拟化(hypervisors), 容器化(e.g. Docker), 基础设施即服务 (IaaS), 工作负载虚拟化(Kubernetes,Spark…)等；

10、服务平台化(PaaS)： 云服务平台上具有自动缩放、工作负载管理、SLA 管理、消息机制、缓存、构建管理等各种按需使用的服务；

11、新的可替代数据持久化模型：如NoSQL, MapReduce, BASE, CQRS等；

12、标准化代码管理：如Github等

这一切都催生了新的架构设计风格 – 微服务架构的出现。

二、什么是微服务？

微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成很多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP RESTful API 进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写。  尽管“微服务”这种架构风格没有精确的定义，但其具有一些共同的特性，如围绕业务能力组织服务、自动化部署、智能端点、对语言及数据的“去集中化”控制等。

三、微服务具备哪些特点？

（1）按照业务来划分服务，单个服务代码量小，业务单一，易于维护。

（2）每个微服务都有自己独立的基础组件，例如数据库、缓存等，且运行在独立的进程中。

（3）微服务之间的通信是通过HTTP 协议或者消息组件，且具有容错能力。

（4）微服务有一套服务治理的解决方案，服务之间不相合，可以随时加入和剔除服务。

（5）单个微服务能够集群化部署，并且有负载均衡的能力。

（6）整个微服务系统应该有一个完整的安全机制，包括用户验证、权限验证、资源保护等。

（7）整个微服务系统有链路追踪的能力。

（8）有一套完整的实时日志系统。
原文链接：https://blog.csdn.net/LUCKWXF/article/details/90518611

四、微服务具备哪些功能？

微服务具有以上这些特点，那么微服务需要具备一些什么样的功能呢？微服务的功能主要 体现在以下几个方面。

1、服务的注册和发现。 2、服务的负载均衡。 3、服务的容错。 4、服务网关。 5、服务配置的统一管理。6、链路追踪。 7、实时日志。

参考链接：https://blog.csdn.net/LUCKWXF/article/details/90518611

知识有限，以后再了解；

本文结束！