10.1 微服务：服务本身的设计，维护及治理
序曲：微服务架构核心：服务本身的设计维护及治理。
微服务框架是基础:（Spring framework,Spring boot,Spring Cloud）
首先设计好微服务本身；其次选择一个合适的微服务框架。
0.巨无霸单体应用系统带来的问题
1.编译，部署困难。
2.代码分支管理困难。
3.数据库连接耗尽：巨型应用，大量访问，必然需要将这个应用部署在一个大规模的服务器集群上，应用与数据库的连接通常使用数据库连接池，
以每个应用 10 个连接及，一个数百台的服务器集群的应用需要再数据库上创建数千个连接，数据库服务器上，每个连接都会占用一些昂贵的系统资源，
以至于数据库缺乏足够的系统资源进行一般的数据操作。
4.新增业务困难。
解决方案：拆分，将模块独立部署，降低系统耦合性。
纵向拆分：将一个大应用拆分为多个小应用，如果新增业务较为独立，那么就直接将其设计部署为一个独立的 Web 应用系统。
横向拆分：将复用的业务拆分出来，独立部署为微服务，新增业务只需要调用这些微服务及可快速搭建一个应用系统。
1.微服务框架
Web Service 与企业级分布式服务-----SOA 架构
Web Service 虽然有成熟的技术规范和产品实现，以及在企业应用领域有许多成功的案例，但是也具有一些固有的缺点：
臃肿的注册与发现机制
低效的 XML 序列化手段
开销相对较高的 HTTP 远程通信
复杂的部署与维护手段
这些问题导致 Web Service 难以满足大型网站，对系统高性能，高可用，已部署，易维护的要求。
2.微服务框架需求
对于大型互联网系统，除了 Web Service 所规范的服务注册与发现，服务调用等标准功能，还需要微服务框架能够支持：
负载均衡：
对于集群部署的服务提供者，服务请求者可以使用加权轮询等手段访问，是服务提供者集群实现负载均衡。
失效转移(Fail Over)：
对于大型网站的微服务而言，即时是很少访问的简单服务，也需要集群部署，
同时微服务框架还需要支持服务提供者的失效转移机制，以实现服务高可用。
高效的远程通信：
对于大型网站，核心服务每天的调用次数会达到数以亿计，如果没有高效的远程通信手段，
服务调用可能会成为整个系统性能的瓶颈。
对应用的最少侵入：
网站技术是为业务服务的，是否使用微服务需要根据业务发展规划，微服务也需要渐进式的演化，甚至出现反复。
即使用了微服务后又退回到集中式部署，微服务框架需要支持这种渐进式演化和反复。
当然服务模块本身需要支持可集中式部署，也可以分布式部署。
版本管理：
为了应对快速变化的需求，服务版本升级不可避免，如果仅仅是服务实现升级，那么这种升级对服务请求者而言是透明的，无需关注。
但是服务的访问接口发生变化，就需要服务请求者和服务提供者同时升级才不会导致服务调用失败。企业应用系统可以申请停机维护，
同时升级接口，而网站应用不可能中断，需要服务提供者先升级接口，并同时提供历史版本的服务供请求者调用，当请求者访问接口升级后，
才可以关闭历史版本服务。
3.微服务框架(Dubbo)架构
Dubbo 微服务框架解决的问题：负载均衡，失效转移，高效远程通信，进入性，版本管理等。
解析：三个角色：
1.Service Producer(服务生产者)：
注册：在服务管理容器中启动，根据服务描述文件，注册服务生产者到服务注册中心。（接口名称，请求参数，服务在哪些服务器上，IP，端口号）
2.Service Consumer(服务消费者)：
消费：服务消费者调用服务接口（物理上的 Java 接口）。
服务接口通过“接口访问代理”调用 Dubbo 微服务框架的客户端。
客户端去注册中心查找“服务接口名称”对应的服务提供者列表(IP+Port),通过负载均衡策略选择其中一个（IP+Port）。
客户端真正的与其中一个微服务通信。远程通信模块建立长连接，发送请求参数。Dubbo 协议解析调用的接口是哪个，解析出传递的参数，代码在哪里，调用实现类，实现类调用完成。将结果使用私有化协议通过远程通信模块返回给客户端，再返给消费者程序。
服务接口：既可以远程，又可以本地，实现服务的透明代理。服务既可以远程部署，又可以本地部署。既可以微服务，又可以集中部署。
3.Service Register Center(服务注册中心)：
还未添加个人签名 2018.05.02 加入
还未添加个人简介
评论