初识微服务

初识微服务

        刚从传统开发跳槽进入一家使用微服务架构的公司,感觉还是有很多不适应,所以赶紧利用网络资源去了解了一下微服务到底是什么,之前天天听别人说微服务多么流行多么厉害,现在终于有幸也来设身处地的来接触微服务了.

      概念

        要想使用,必先了解什么是微服务.顾名思义,微服务可以拆分成"微"和"服务",简单来说,就是将一个服务拆分成很多微小的服务,他们都可以不依赖彼此单独执行.这也导致我以前的单模块开发瞬间变成了多个模块.微有多微,这个取决于架构师的将服务拆分的粒度.服务之间则通过网络通信相互调用.微服务只关心自己关注的某个功能.下面是画的一个简单的架构图

        

     优缺点(主体为单体应用架构)

        优点:

        1.    易于开发和维护: 由于是很微小的服务,代码量较少.只关注某个功能,所以维护起来容易.并且重新启动单个模块容易,出了问题也容易定位修改.

        2.    无需重启整个项目: 项目上线后,如果单个模块出了问题,可以在不停下整个系统的情况下,停掉单一的模块去处理,然后在不影响其他业务的前提下重新启动.

        3.    按需伸缩: 可以根据业务不同的访问量等方面对于服务器做升级而不浪费资源.

        4.    不限制语言: 每个服务都可以根据需求使用不同的开发语言.只需要完成相应的功能即可.

        缺点:

        1.    运维要求高: 微服务被拆分的粒度越小,所需的服务器越多,更多的服务器就需要监测和维护,增加了运维的工作量.

        2.    改接口成本高: 服务间都是用接口调用,如果某个接口有改动,那所有的掉用该接口的服务都要做修改.

        3.    重复代码: 每个服务只关心自己的功能,但有些功能可能有穿插,于是就可能两个服务之间都有相同的功能,于是就会有重复的代码.

        4.    分布式固有的问题: 比如说分布式事务处理,网络延迟,一致性和高可用性等.

     设计原则

        1.    单一职责: 每个服务只关心自己的功能,这也与微服务架构的理念相对应.

        2.    服务自治: 每个服务都具备单独的业务能力,环境和依赖.应与其他服务高度解耦,可以单独的开发,部署,测试,发布而不依赖别的服务.

        3.    轻量级网络通信: 有两点

                a.    通信本身很轻

                b.    跨语言

                说到这里,不经想起了一个黑科技: 谷歌的protobuf,可以将对象压缩到很小,有兴趣的小伙伴可以去了解一下,需要一定的学习成本.虽然有点偏题,不属于网络通信协议.

        4.    微服务粒度: 这个东西是微服务中的一个难点,并不是说微服务越小越好,要合理的划分服务粒度.难就难在怎么个合理法,这就要引用到领域驱动的设计思想了,其中的界限上下文可作为划分界限,服务粒度的依据.但是由于对于领域驱动并不算太了解,所以就不做过多描述了.

     技术选型

        开发框架选型: 推荐选择springcloud,作为一个以springboot为基础的开箱机用的框架,无论是开发文档还是社区活跃度都是比较不错的,并且springcloud为微服务提供了完整的解决方案.当然也可以选择zookeeper和dubbo的组合.

        运行平台: 推荐选择docker,其轻量,灵活,比较适合微服务,当然也可以用各种平台如阿里云,PC.