菜鸟的微服务之旅(1)---认识微服务(上)

1.历史的演变

传统单体应用架构--->SOA(Service-Oriented-Architecture)面向服务的架构--->微服务架构

传统单体应用机构早期处理用户量少，配合负载均衡可以很好的满足使用需求。但是因为其是将应用整体打包部署，随着项目的多次开发会导致：(1)应用臃肿，维护及二次开发困难。(2)通过负载均衡可以水平拓展，但是不需要的功能也会随着单体应用架构而被多次扩展，造成冗余代码增加，造成系统资源的浪费。(3)应用增加，其启动时间也增长，影响开发效率。(4)健壮性差，局部bug会带崩整个应用。(5)如果要进行应用技术更新迭代，则需要全部重新开发，这种成本无疑是巨大的。

既然传统单体应用机构的缺点已经暴露无疑。那么针对这个问题，大部分企业通过SOA来解决上述问题。那么SOA又是什么东西，如何解决这些问题的呢？SOA的思路是将应用中相近的功能模块聚合到一起，以服务的形式提供出去。简单说就是在将原本传统的单体架构，按照功能细分成不同的子系统，然后各个子系统依赖服务中间件(ESB)来调用需要的服务。但是尽管如此解决了大部分单体架构存在的弊端，但是归根究底，SOA相互独立的服务还是会部署在一个运行环境中，在之后业务的升级拓展，SOA的服务会更加复杂，这样看来，SOA并没有完全解决单体架构的问题。

那么怎么处理这样的问题呢？重头戏来了，就是我们的微服务架构思想。微服务架构就是让我们在传统单体架构的基础上，通过业务功能拆分成更细粒度的服务，注意了！！这里所拆分的每一个服务都是独立的应用，这些应用可以对外提供公共的api，可以独立承担对外的职责，这就是微服务。

而微服务所具备的优点就有以下几点：

(1)复杂度可控   微服务体积小，复杂度低  可以由不同小组独立完成，高可维护性，也同时提供了开发效率。

(2)可独立部署   既然作为独立的小应用，那当然具备独立部署的条件。首先提高了部署效率，其次降低了对生产环境造成的影响，缩短了应用交付周期。

(3)技术选型灵活  因为其相互独立开发的小应用，在技术的迭代上有良好的更新条件，开发花费低，对生产环境造成的影响低，可以在保留原技术的前提下，新建一个新应用来实现新技术，这样可以良好迭代并保证应用的安全。

(4)易于容错   相互独立的应用  就保证了局部bug对整体应用不会造成太大影响，在微服务架构下，故障会被隔离在某单个服务中，便于处理及维护。

(5)易于拓展  不同组件的拓展不会存在问题，微服务架构有其灵活性，因为每个服务节点都可以根据需求进行拓展。

(6)功能特定  每个单个服务节点都是某个特定的功能

当然，微服务架构也不是十全十美：

(1)开发人员必须处理创建分布式系统的复杂性    服务众多，每个服务都是独立的业务单元，如何保证彼此的依赖正常。

(2)部署的复杂性 

(3)增加内存消耗  每个服务节点都运行自己的jvm   那么多个服务实例，就会有多少实例造成在运行时的内存开销。

 

----本文读《微服务架构基础》有感，引用其内容作为笔记记录 供广大学者参考学习。如有侵权，请及时告知。