java⼩程序开发难点，赶紧收藏！
微服务是什么
微服务起源于2005年Peter Rodgers博⼠在云端运算博览会提出的微Web服务(Micro-Web-Service)，根本思想类似于Unix的管道设计理念。2014年，由Martin Fowler 与 James Lewis共同提出了微服务的概念，定义了微服务架构风格是⼀种通过⼀套⼩型服务来开发单个应⽤的⽅法，每个服务运⾏在⾃⼰的进程中，并通过轻量级的机制进⾏通讯（HTTP API）。关键的三点是small、automated以及lightweight。
对⽐SOA，微服务可以看做是SOA的⼦集，是轻量级的SOA，粒度更细的服务，独⽴进程、数据分离，更注重敏捷、持续交付、DevOps 以及去中⼼化实践。其共同的架构原理：
单⼀职责
关注分离：
控制与逻辑相分离
模块化和分⽽治之
特点：
⽤服务进⾏组件化
围绕业务能⼒进⾏组织
是产品⽽⾮项⽬
端点智能化和哑管道: 控制逻辑都在端点，管道仅仅是传输
全⾃动化部署
语⾔和数据的去中⼼化控制
⾯向失败设计
渐进式设计
综合来看，其优缺点如下：
优点：
模块的强边界
独⽴部署
技术选型的多样性
缺点：
分布式带来编程复杂度，远程调⽤的消耗
舍弃强⼀致性，实现最终⼀致性
操作复杂性要求有⼀个成熟的运维团队或者运维基础设施
为什么要采⽤微服务
是否选择微服务取决于你要设计的系统的复杂度。微服务是⽤来把控复杂系统的，但是随之⽽来的就是引⼊了微服务本⾝的复杂度。需要解决包括⾃动化部署、监控、容错处理、最终⼀致性等其他分布式系统⾯临的问题。即使已经有⼀些普遍使⽤的解决⽅案，但是仍然是有不⼩的成本的。
⽣产⼒和复杂度的关系如图所⽰，可见系统越复杂，微服务带来的收益越⼤。此外，⽆论是单体应⽤还是微服务，团队的技能都需要能够把控住。
马丁.福勒的⼀个观点是：除⾮管理单体应⽤的成本已经太复杂了（太⼤导致很难修改和部署），否则都不要考虑微服务。⼤部分应⽤都应该选择单体架构，做好单体应⽤的模块化⽽不是拆分成服务。
因此，系统⼀开始采⽤单体架构，做好模块化，之后随着系统变得越来越复杂、模块/服务间的边界越来越清晰，再重构为微服务架构是⼀个合理的架构演化路径。
四个可以考虑上微服务的情况：
1. 多⼈开发⼀个模块/项⽬，提交代码频繁出现⼤量冲突。
2. 模块间严重耦合，互相依赖，每次变动需要牵扯多个团队，单次上线需求太多，风险⼤。
3. 主要业务和次要业务耦合，横向扩展流程复杂。
4. 熔断降级全靠if-else。
微服务的三个阶段：
1. 微服务1.0：
仅使⽤注册发现，基于SpringCloud或者Dubbo进⾏开发。
2. 微服务2.0：
使⽤了熔断、限流、降级等服务治理策略，并配备完整服务⼯具和平台。
3. 微服务3.0：
Service Mesh将服务治理作为通⽤组件，下沉到平台层实现，应⽤层仅仅关注业务逻辑，平台层可以根据业务监控⾃动调度和参数调整，实现AIOps和智能调度。
微服务架构
先决条件
快速的环境提供能⼒：
依赖于云计算、容器技术，快速交付环境。
基本的监控能⼒：
包括基础的技术监控和业务监控。
快速的应⽤部署能⼒：
需要部署管道提供快速的部署能⼒。
Devops⽂化：
需要具有良好的持续交付能⼒，包括全链路追踪、快速环境提供和部署等，还需要快速的反应能⼒（对问题、故障的快速响应），开发和运维的协同⼯作。
此外，根据康威定律和逆康威定律（技术架构倒逼组织架构改进），组织架构也是⼀个很关键的因素。对应于微服务架构，组织架构需要遵循以下原则：
1. ⼀个微服务由⼀个团队维护，团队成员以三⼈为宜。
2. 单个团队的任务和发展是独⽴的，不受其他因素影响。
3. 团队是功能齐全、全栈、⾃治的，扁平、⾃我管理。
基础设施
微服务的推⾏需要依赖于很多底层基础设施，包括提供微服务的编译、集成、打包、部署、配置等⼯作，采⽤PaaS平台解决微服务从开发到运⾏的全⽣命周期管理，同时提供异构环境管理、容器资源隔离与互通、服务伸缩漂移、服务升级与回退、服务熔断与降级、服务注册与发现。
1. 最基本的基础设施
进程间通讯机制：
微服务是独⽴进程的，需要确定之间的通讯⽅式。
服务发现+服务路由: 提供服务注册中⼼，服务提供者和消费者通过服务发现获取服务的信息从⽽调⽤服务，实现服务的负载均衡等。
服务容错：
微服务架构中，由于服务⾮常多，往往是⼀个服务挂了，整个请求链路的服务都受到影响，因此需要服务容错，在服务调⽤失败的时候能够处理错误或者快速失败，包括熔断、fallback、重试、流控和服务隔离等。
入门的java游戏小程序
分布式事务⽀持：
随着业务拆分为服务，那么有时候不可避免的就是跨服务的事务，即分布式事务的问题。
原则是尽量避免分布式事务，如果⽆法避免那么可以使⽤消息系统或者CQRS和Event Sourcing⽅案来实现最终⼀致性。
如果需要强⼀致性，则有两阶段提交、三阶段提交、TCC等分布式事务解决⽅案。
3. 提升外部服务对接效率和内部开发效率
API⽹关: 负责外部系统的访问，负责跨横切⾯的公共层⾯的⼯作，包括安全、⽇志、权限控制、传输加密、请求转发、流量控制等。
典型的⽹关功能即对外暴露⼀个域名xx，根据第⼀级⽬录做反向路由xx/user，xx/trade。
每⼀级⽬录，如user、trade对应⼀个服务的域名。
此外，API⽹关也可以有服务编排的功能（不推荐）。
接⼝框架: 规范服务之间通讯使⽤的数据格式、解析包、⾃解释⽂档，便于服务使⽤⽅快速上⼿等。
5. 提升测试和运维效率
持续集成：
这⼀部分并⾮是微服务特定的，对于之前的单体应⽤，此部分⼀般来说也是必要的。
主要是指通过⾃动化⼿段，持续地对代码进程编译构建、⾃动化测试，以得到快速有效的质量反馈，从⽽保证代码的顺利交付。
⾃动化测试包括代码级别的单元测试、单个系统的集成测试、系统间的接⼝测试。
⾃动化部署：
微服务架构，节点数动辄上百上千，⾃动化部署能够提⾼部署速度和部署频率，从⽽保证持续交付。
包括版本管理、资源管理、部署操作、回滚操作等功能。
⽽对于微服务的部署⽅式，包括蓝绿部署、滚动部署以及⾦丝雀部署。
配置中⼼: 运⾏时配置管理能够解决动态修改配置并批量⽣效的问题。
包括配置版本管理、配置项管理、节点管理、配置同步等。
持续交付：
包括持续集成、⾃动化部署等流程。
⽬的就是⼩步迭代，快速交付。
8. 进⼀步提升运维效率
服务监控: 微服务架构下节点数⽬众多，需要监控的机器、⽹络、进程、接⼝等的数量⼤⼤增加，需要⼀个强⼤的监控系统，能够提供实时搜集信息进⾏分析以及实时分析之上的预警。
包括监控服务的请求次数、响应时间分布、最⼤/最⼩响应值、错误码分布等
服务跟踪：
跟踪⼀个请求的完整路径，包括请求发起时间、响应时间、响应码、请求参数、返回结果等信息，也叫做全链路跟踪。
通常的服务监控可以和服务监控做在⼀起，宏观信息由服务跟踪呈现，微观单个服务/节点的信息由服务监控呈现。
服务跟踪⽬前的实现理论基本都是Google的Dapper论⽂。
服务安全：
内⽹之间的微服务调⽤原则上讲应该是都可以互相访问写，⼀般并不需要权限控制，但有时候限于业务要求，会对接⼝、数据等⽅⾯有安全控制的要求。
此部分可以以配置的⽅式存在于服务注册中⼼中，和服务绑定，在请求时由做为服务提供者的服务节点进⾏安全策略控制。
配置则可以存储在配置中⼼以⽅便动态修改。
在微服务数量很少的情况下，以上基础设施的优先级⾃上⽽下降低。否则，仅仅依赖⼈⼯操作，则投⼊产出⽐会很低。
还需要提到的是Docker容器技术。虽然这个对于微服务并不是必须的，但是容器技术轻量级、灵活、与应⽤依存、屏蔽环境差异的特性对于持续交付的实现是⾄关重要的，即使对于传统的单体应⽤也能够给其带来交付效率的⼤幅提升。
架构设计模式
在引⼊微服务之后，传统的单体应⽤变为了⼀个⼀个服务，之前⼀个应⽤直接提供接⼝给客户端访问的架构不再适⽤。微服务架构下，针对不同设备的接⼝做为BFF层（Backend For Frontend），也叫做⽤户体验适配层，负责聚合、编排微服务的数据转换成前端需要的数据。服务之间的调⽤则在允许的情况下（允许延迟）尽可能使⽤异步消息传递⽅式，如此形成⾯向⽤户体验的微服务架构设计模式。如下图所⽰：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。