微服务架构优势在哪，与传统服务区别是什么，程序员必掌握
一、概述
说起微服务，在程序界，可算是当下相对火爆的词，那么微服务到底是什么？与传统的服务有什么区别，为什么要使用微服务呐？
需要指出的是：微服务架构并不是为了拆分而拆分，真正的目的是通过对微服务进行水平扩 展解决传统的单体应用在业务急剧增长时遇到的问题，而且由于拆分的微服务系统中专业的人做 专业的事，人员和项目的职责单一、低藕合、高内聚，所以产生问题的概率就会降到最小。
二、微服务架构描述
先看看微服务的架构图，看看当前火的微服务架构图：
从图得出如下结论：
· 微服务把每一个职责单一的功能放在一个独立的服务中 。
· 每个服务运行在一个单独的进程中。
· 每个服务有多个实例在运行，每个实例可以运行在容器化平台内，达到平滑伸缩的效 果。
· 每个服务有自己的数据存储，实际上，每个服务应该有自己独享的数据库、缓存、消息 队列等资源。
· 每个服务应该有自己的运营平台，以及独享的运营人员，这包括技术运维和业务运营人 员：每个服务都高度自治，内部的变化对外透明。
· 每个服务都可根据性能需求独立地进行水平伸缩 。
三、传统架构描述
先看看传统架构图，粗略看看传统架构的实现方式：
从上图可以得到如下结论：
·传统单体架构将所有模块化组件混合后运行在同一个服务 口而4 进程中 。
· 可对包含多个模块化组件的整体 川岛f 进程进行水平扩展，而无法对某个模块化组件进 行水平扩展。
· 某个模块化组件发生变化时，需要所有的模块化组件进行编译、打包和上线 。
· 久而久之，模块间的依赖将会不清晰，互相糯合、互相依赖成为家常便饭。
通过对比来看，微服务架构更灵活并且可水平伸缩，可以让专业的人来做专业的事。
到了这里可能很多初级程序员会觉得这些有些难懂， 没关系，我为大家准备了一套精品PHP教程，里面涵盖Nginx，Memcached，微服务框架等学习教程，如果你已经了解过，想要精通进阶中高级PHP，我这里也有专注于PHP中高级进阶的教程，点击下方标题链接即可获取方法！
全套laravel框架、ThinkPHP框架全套教程分享，PHP程序员福利！
PHP开发三年只懂增删改查？那是你没有规划好php学习路线
四、微服务架构与传统单体架构的对比
单块架构应用：功能集中，代码和数据中心化，一个发布包部署后运行在同一个进程中的应用程序
单块架构的优势：
1）易于开发
2）易于测试
3）易于部署
4）易于水平伸缩(所有的功能都会打成一个包，在集群中新建一个节点，配置好节点的运行环境，复制软件包到响应的位置，保证负载均衡的分发策略有效分发到当前节点即可)
面临的挑战：
1）维护成本增加，代码量过大，不利于快速定位问题
2）持续交付周期长：构建 部署和测试的实际都会随着代码量的增加而成倍的增长
3）新人培养周期长：业务熟悉和环境部署都会有很大的难度
4）技术选型成本高：较大规模的系统，最初的选型会影响新技术的使用
5）可扩展性差：
a 垂直扩展：增加服务器
b 水平扩展：在集群中添加节点，使用负载均衡(若应用有一部分是需要内存密集型缓存大量数据，有一部分是需要CPU密集型，需要进行大量运算，那么每次扩展新的节点都需要足够的内存和CPU来满足需求)
6）构建全功能团队难：会出现功能的扩展需要跨团队沟通
微服务架构：
- 是一种架构模式，提倡将单一应用程序划分为一组小的服务，服务之间相互协调，相互配合，为用户提供最终价值，每个服务运行在独立的进程中，服务间采用轻量级的通信机制相互沟通(通常是基于http的restful api)，每个服务围绕自己的具体业务构建，可以独立部署，应尽量避免统一的，集中式的服务管理机制，对于具体的一个服务而言，应根据业务上下文，选择合适的语言 工具来进行构建，也就是：
- 通过对特定业务领域的分析和建模，将复杂的应用分解成小而专一的，耦合度低并且高度自治的一组服务，每一个服务都是一个小的应用
- 编译语言有良好的语言类型约束和编译期检查，但代码比较复杂
- 动态语言灵活性高，运行时可以改变其内存结构，无类型检查，无需写交较多类型相关的代码，但不方便调试
- 开发 测试 部署完全独立，语言独立
- 服务与服务之间相互独立，相互隔离
在单块架构中，应用程序的代码虽然被分成逻辑上的3层或者4层，但并非物理上的分层，所有的功能经过编译，打包，部署后还是会运行在同一个进程中，这就意味着对应用部署时必须停掉正在运行的服务，部署完成后再重新启动进程，无法独立部署
一般为了代码的重用性，会把重复的代码封装成组件(可独立升级，独立替换掉的部分)，传统架构中，通常是共享库，比如jar包或者是win下的dll等
但在微服务架构中，应用程序由多个服务组成，每个服务都是一个具有高度自治的独立业务实体，每个服务可以运行在一个独立的进程中，不同的服务可以轻易的部署到不同的主机上
理论上可以把不同的服务部署到同一个节点上，运行到不同的进程里，但是不推荐，既然是微服务，最好保证高度的自治性和隔离性，运行在同一个节点上，虽然省去了节点的开销，却增加了部署和扩展的复杂度，部署某一个新的服务时，可能会对该节点的原有服务造成影响，另外随着业务的发展，可能某些业务需要水平扩容，有些不需要，如果不能有效的组织服务，可能会给服务的水平扩容带来不必要的麻烦。