首页手记微服务架构初识

微服务架构初识

标签：

Sass/Less

总结自己对微服务架构整体的一个浅层次认知，主要包括以下9个方面认知。

一．微服务

①什么是微服务？

微服务就是一些协同工作的小而自治的服务，称之为分布式系统，是SOA（面向服务的架构）架构的一种实现方法。

单个服务多小合适？应该考虑这些因素：服务越小，服务架构的优点和缺点也就越明显。使用的服务越小，独立性带来的好处越多，但是管理大量的微服务也会越复杂。

单个服务的自治性特点。一个服务就是一个独立的实体。每一个服务暴露出API,服务之间以网络为媒介通过这些API调用进行通信。从而加强了服务之间的隔离性，避免紧耦合。

②微服务带来的好处？

(1)技术异构性。

不同的服务使用最适合该服务的技术。如果系统中的某一部分需要做性能提升，可以使用性能更好的技术栈重构该服务。如系统中不同的服务可以使用不同的数据库存储技术。微服务可以帮助我们更快地采用新技术，并降低风险。

(2)弹性。

弹性工程学的一个关键概念是壁舱。如果系统中一个组件不可用了，但并没有导致级联故障，那么系统的其他部分还可以正常运行。服务的边界就是一个很显然的壁舱。微服务可以很好的处理服务不可用和功能降级问题。微服务以网络为媒介进行RPC通信，网络会是瓶颈问题。

(3)易拓展。

微服务架构相比单系统来说更易拓展。

(4)易部署。

微服务部署风险低，效率高。

(5)易管理。

微服务架构，更易实现团队自治，开发效率更高，维护成本更低。

(6)可重用。

微服务架构，对于独立的服务，可实现可重用，易于组合的目的。

(7)易重构。

开发团队在必要的时候可以轻易实现对单个服务的重构或重写，或删除不再使用的服务。

③相关术语。

（1）SOA（Service-Oriented Architecture,面向服务的架构）。实施SOA通常要考虑:通信协议的选择，第三方中间件的选择，服务粒度的划分等。

（2）OSGI(Open Source Gateway Initiative,开放服务网关协议)。OSGI是一种模块分解技术，强调模块生命周期管理，允许在一个进程内部进行模块划分，创建出相对隔离的模块避免耦合。Java9已加入这个特性。但不推荐这么做。

二.建模微服务

①好的微服务特点？

(1)松耦合

服务之间松耦合，要求能够做到能够修改及部署单个服务而不需要修改系统的其它服务。一个松耦合的服务应该尽可能少的知道与之协作的服务的信息。否则服务之间过度通信会导致紧耦合。

(2)高内聚

把相关的行为聚集在一起，把不相关的行为放在别处。达到这样的目的，当需要修改某个行为时，最好只对一个服务进行修改，而不需修改其它服务，达到快速发布，降低风险，快速交付。所以找到问题的边界，确定划分服务的粒度是关键。

②建模微服务

建模微服务，应该以服务所提供的功能为出发点，进行微服务的建模。

三．集成服务

微服务，每一个单独的服务所提供的功能相对单一，但每一个服务的的功能实现可能要集成其它服务的功能。集成是微服务架构中一种常用的手段。

①服务之间的通信方式-同步/异步

（1）同步

使用同步通信，发起一个远程服务调用之后，调用方会阻塞自己并等待整个远程调用过程的完成，才可以返回。

同步调用，基于“请求/响应”的模式。客户端发起一个请求，然后等待响应。

编排的架构风格，即采用同步调用，“请求/响应”模式，可以清楚知道每一步的响应结果，却会导致系统臃肿，响应耗时，耦合度高。

（2）异步

使用异步通信，调用方不需要等待远程调用过程的完成，就可以返回。

异步调用，基于“事件发布”的模式。客户端不是发起请求，而只是发布一个“事件”，并不知道谁会对此事件作出响应。

协同的架构风格，即采用异步调用，“事件发布”模式，可降低系统耦合度，响应更快速；但需要额外的工作对对业务流程做跨服务监控。

②同步通信实现技术-RPC/REST

RPC(Remote Procedure Call)远程过程调用；

REST(Representational State Transfer)表述性状态转移。

（1）RPC

远程调用，允许你进行一个本地调用，但事实上结果是由某个远程服务器产生的。远程调用的协议种类繁多，如Java RMI，Thrift,Protocol buffers等是使用二进制作为消息的传输格式；SOAP使用XML作为消息的传输格式。

RPC会花费时间对传输信息进行封装和解封装，网络通信耗时也是需要考虑的因素；通信双方对使用的数据模型依赖较重，数据类型会直接被序列化和反序列化，导致不再使用的字段无法被安全删除。

RPC可以帮助你生成客户端桩代码，可以支持高级的序列化和反序列化机制，以及更加灵活的通信协议。

（2）REST

REST是受Web启发产生的，能够使客户端和服务端对数据模型的依赖弱化，更加灵活。

REST风格多用Http协议，数据传输格式灵活，JSON,XML及二进制格式都可以。

③异步通信实现技术-MQ

异步通信，基于“事件发布”机制。耦合度低，伸缩性好；但编程的复杂性更高，常用的成熟技术手段是采用“消息队列”实现。

④集成微服务考虑要素

（1）服务的响应延时

（2）服务不可用，合理安全的功能降级

四．分解单个系统

分解单个臃肿的系统，使其拆分成多个微服务。

①分离数据库

建议先分离数据库结构，再分离服务。

②慎重处理分布式事务

把单个系统拆分为多个微服务，可能会产生分布式事务。分布式事务横跨多个系统，运行在不同系统的不同进程中。分布式事务通常通过重试和补偿机制来达到最终的一致性。

五．部署

①CI(Continuous Integration)持续集成。

CI能够保证新提交的代码与已有的代码进行集成，从而让所有人保持同步。通过CI能够从已部署的构建物回溯到响应的代码。把CI构建和每个微服务映射起来，每个服务独立于其它服务进行独立部署。

②CD(Continuous Delivery)持续交付。

CD能够检查每次提交是否达到了部署到生产环境的要求，并持续的把这些信息反馈，它会把每次提交当成候选发布版本来对待。

③实施蓝/绿部署

蓝绿部署时，我们会部署两份软件，只有一份接受真正的请求。如把新新版本的服务用于接受请求，并保留旧版本一段时间，确保发生错误时，能够快速恢复到旧的版本。

④金丝雀发布

金丝雀发布是指通过将部分生产流量引流到新部署的系统，来验证系统是否按预期执行。金丝雀发布与蓝绿部署的不同之处在于，新旧版本共存时间更长，而且经常会调整流量。

六．测试

①单元测试

单元测试，通常用来测试函数和方法调用。TDD(Test-Driven Design)测试驱动开发，就属于单元测试。

②服务测试

服务测试，是针对暴露的服务功能进行测试。一个服务测试只测试其中一个单独服务功能。

七．监控

微服务会增加生产系统监控的复杂性。监控的的手段是：监控单个服务，然后聚合起来看整体。

如，对每一个微服务进行埋点日志，然后聚合日志信息做整体分析；如对每一台运行的机器利用辅助监控工具，统计的cpu,内存等资源使用占比等信息。

八．安全

①身份验证和授权

身份验证和授权一种实现手段是，使用某种形式的SSO(Single Sign-On)单点登录解决方案。当请求试图访问一个资源，它会被定向到一个身份提供者哪里进行身份验证。这个身份提供者要求它提供用户名和密码，或是使用双重身份验证。当身份提供者确认请求已通过身份验证，它会发消息给服务提供者，让服务提供者决定是否允许访问资源。

如常用的SAML和OpenID Connect等解决方案提供了这方面的能力。

②HTTP(S)基本身份验证

③携带密钥形式的验证

④数据加密传输，如采用AES对称加密算法加密传输

⑤深度防御，如防火墙机制，网络隔离等手段

九．微服架构指导思想

①4个设计原则

（1）AKF拆分原则（指“负载均衡”，“数据分区”，拆分为微服务）

（2）前后端分离

（3）无状态服务

（4）Restful通信风格

②一些实践指导思想