一、什么是微服务
微服务是一种架构风格,一个大型复杂应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。
二、为什么要使用微服务
1.最初是没有服务层的,此时架构会碰到什么典型痛点呢?
痛点一:代码到处拷贝
各个业务线都是自己通过DAO写SQL访问user库来存取用户数据,这无形中就导致了代码的拷贝。
痛点二:复杂性扩散
随着并发量的越来越高,用户数据的访问数据库成了瓶颈,需要加入缓存来降低数据库的读压力,于是架构中引入了缓存,如果没有统一的服务层,各个业务线都需要关注缓存的引入导致的复杂性。
痛点三:SQL质量无法保障,业务相互影响
业务线通过DAO访问数据库,本质上SQL语句还是各个业务线拼装的,资深的工程师写出高质量的SQL,经验没有这么丰富的工程师可能会写出一些低效的SQL。
假如业务线A写了一个全表扫描的SQL,导致数据库的CPU100%,影响的不只是一个业务线,而是所有的业务线都会受影响。
痛点四:DB耦合
业务线不只访问user数据,还会结合自己的业务访问自己的数据。典型的,通过join数据表来实现各自业务线的一些业务逻辑。
业务线A的table-user与table-A耦合在了一起,业务线B的table-user与table-B耦合在了一起,业务线C的table-user与table-C耦合在了一起,结果就是:table-user,table-A,table-B,table-C都耦合在了一起。
2.服务化后,高可用架构如何?
好处一:简化调用方式
有服务层之前,业务方访问用户数据,需要通过DAO拼装SQL访问。
有服务层之后,业务方通过RPC(远程过程调用)访问用户数据,就像调用一个本地函数一样,不需要关心序列化,网络传输,后端执行,网络传输,范序列化等复杂性。
好处二:复用性,防止代码拷贝
所有数据都是通过服务存取,代码只此一份,不存在拷贝。
好处三:专注性,屏蔽底层复杂度
有了服务层之后,所有的SQL都是服务层提供的,业务线不能再为所欲为了。底层服务对于稳定性的要求更好的话,可以由更资深的工程师维护,而不是像原来SQL难以收口,难以控制。
好处四:数据库解耦
服务化之后,底层的数据库被隔离开了,可以很方便的拆分出来,进行扩容。
好处五:提供水平扩展
在服务化之前,各业务线上游想怎么操纵数据库都行,遇到了性能瓶颈,各业务线容易相互推诿。
服务化之后,服务只提供有限的通用接口,理论上服务集群能够提供无限性能,性能出现瓶颈,服务层一处集中优化。
好处六:独立部署,快速迭代
方便项目的迭代快速部署
三、怎么进行微服务
从生产力和系统的复杂性这两个方面来看。公司一开始的时候,业务复杂性不高,这时候是验证商业模式的时候,业务简单,用单体服务反而生产力很高。随着公司的发展,业务复杂性慢慢提高,这时候就可以采用微服务来提升生产力了。设计系统时就直接设计成了微服务,而不是通过单服务慢慢演化发展成微服务。团队之间需要良好的沟通和合作才能实现真正的团队自治。灵活性和责任感应该贯穿整个应用程序生命周期。