微服务的本质就一个字：拆？

良好的软件体系架构是软件系统设计、开发的基础，可以使系统具有良好的重用性和扩展性。

随着计算机技术的发展，传统的单体架构由于灵活性和扩展性较差，逐渐无法满足软件开发的需求。

因此，微服务作为一种新的架构风格被提出。

与单体架构相比，微服务架构具有易于开发、可独立部署、扩展性强等优点。

一、优势

01

解决了复杂问题，它把可能会变得庞大的单体应用程序分解成一套服务，个体服务能被更快地开发，并更容易理解与维护；

02

微服务架构使得每个服务都可以由一个团队独立专注开发；

03

微服务架构模式可以实现每一个微服务独立部署，使得持续部署成为可能；

04

微服务架构模式使得每个服务能够独立扩展。

但是，微服务架构在带来好处的同时，也带来一些挑战。

在微服务系统中，一个应用会被拆分成若干个微应用，每个微应用都需要对访问进行鉴权，每个微应用都需要明确当前访问用户以及其权限。

在微服务架构下，要考虑外部应用接入的多种鉴权场景。

二、技术解决方案

令牌在客户端生成，由身份验证服务进行签名，并且必须包含足够的信息，以便可以在所有微服务中建立用户身份。

令牌会附加到每个请求上，为微服务提供用户身份验证，这种解决方案的安全性相对较好，但身份验证注销是一个大问题。

客户端Token与API 关结合，意味着所有请求都通过 关，从而有效地隐藏了微服务。在请求时， 关将原始用户令牌转换为内部会话ID令牌。

在这种情况下，注销就不是问题，因为 关可以在注销时撤销用户的令牌。

三、适用性

微服务可以按照业务功能本身的独立性来划分，如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、 络系统、数据库系统等等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就不适合做成微服务了。

目前为止还没有一个可以称之为服务边界划分的标准，只能根据不同的业务系统加以调节。

总结

微服务是更高一级的拆分，微服务意味着每个服务都独立起来。但微服务也意味着管理的更高难度，意味着服务治理更不容易。

从单一服务到微服务，是互联 发展的必然。因为，互联 承载的任务越来越多，其结构必然越来越复杂；结构的复杂性，也意味着其管理结构会采用更合理的方式。但把服务进行拆分，也意味着管理更加困难，这非常考验项目管理者的设计能力。