面对微服务如火如荼的发展, 很多人都在了解, 学习希望能在自己的项目中帮得上忙, 当你对微服务的庐山真面目有所了解后, 接下来就是说服自己了, 到底如何评估微服务, 什么时候使用微服务, 什么时间点最合适, 需要哪些技术储备和资源投入等等, 这些都是你需要面对和解决的.
本文从单体架构, 微服务架构, 微服务风险评估, 微服务落地条件等几个方面探讨微服务的落地过程, 希望对你有所启发.
讲解微服务之前, 我们先简单了解下单体架构.
一, 单体架构
单体架构的优点:
快速开发和验证想法, 证明产品思路是否可行
投入资源和成本, 包括人力和物力相对比较节约
单体架构的缺点:
随着业务的复杂度增加, 单体的灵活度会逐渐下降, 比如:
IDE 过载: 随着代码量增加, 代码整体编译效率下降.
规模化: 无法满足团队规模化高效开发.
系统开发, 测试, 部署的冲突和效率低下等问题
只能关注一套技术栈
应用扩展性比较差
海量用户高并发访问数量有限
单体适用场景:
架构设计的三大原则告诉我们, 架构需要的是简单, 适度, 演化.
对于项目起步阶段, 单体是最高效也是最节省成本的方式. 因为初期阶段, 由于人力, 成本, 业务熟悉程度, 微服务技术积累等因素, 如何过度设计可能工期和复杂度会急剧上升, 造成交付困难, 问题百出, 从而错过了时间窗口. 最合适, 简单的方式还是单体优先, 这是创业公司的特点决定的. 当然设计面向微服务的单体架构也是一种聪明的方法, 这遵守了系统演化的法则.
单体分层目的:
无论采取何种维度的架构分层, 分层的最核心目的是保证各层之间的差异足够清晰, 边界足够明显, 为将来可能产生的变化提供最容易, 最小化的修改. 比如客户端要从安卓替换为 iOS, 底层无须任何改动, 就像替换积木一样. 又比如, 设备需要接入新的设备或协议, 其他层也不需要做任何变化, 可以无缝平滑接入任何设备.
建议
如果前期在业务不十分清晰, 求的是验证想法, 证明产品思路是否可行性, 并且业务量不大, 仅限于省级范围, 建议只要对当前架构稍加改良升级就可以了, 这样改动量相对较小, 且至少能支撑一定时间段的业务增长.
二, 微服务架构
微服务的优势
支撑的业务更加庞大, 可以支撑海量用户高并发和海量设备接入, 支持分布式多机房, 多区域部署, 支持服务器无限扩容. 支持私有云, 公有云, 混合云等部署方式. 所以微服务是大多数互联网公司的首选.
微服务的代价
技术门槛高: 微服务包括, 服务描述, 注册中心, 服务框架, 服务监控, 服务追踪, 服务治理等几大基本组件, 以上每个组件缺一不可, 每个组件展开又包括很多技术门槛, 比如, 容器技术, 持续部署, DevOps 等相关概念.
复杂性增加: 相对单体架构将所有功能打包部署在一起, 集中地进行开发, 测试和运维, 微服务会将这些单体的服务进行拆分部署, 业务拆分粒度是一个难点, 拆分后服务聚合也是一个麻烦. 因为服务粒度增加后, 相互调用, 相互依存, 所以问题排查难度会增加, 就需要一套完整的服务监控, 服务跟踪和治理的系统.
观念变化: 微服务不仅仅是技术的升级, 更是开发方式, 组织架构, 开发观念的转变.
前期投入成本较高
微服务架构图
微服务架构图谱谷歌或 Bing 下, 可以看到各种各样的架构图, 源于业务和架构师自身的喜好或者粗细粒度, 但是每个架构图的基本组件和架构分层都差别不大, 只是有的细一些, 有的粗一下. 比如有客户端层, 容器层(K8S),API Gateway, 微服务集群层, EventBus 层是必须要有的, 至于服务监控和服务跟踪, 服务治理本身就是一个完整的系统, 粒度就没有细了. 基于这些概念, 我把架构图稍微细化一下, 这里省去服务监控跟踪和治理的部分, 后续单独抽离出来分析.
这边的架构图谱相对之前的架构图, 更加贴近业务, 粒度也更细, 虽然个别组件有所省略, 比如跟踪和治理部分.
以上架构图主要分 4 层, 每个层次遵循架构分层的核心思想: 关注点分离, 职责各异, 边界清晰.
第 1 层: 客户端: 理论上包含一切可以联网的设备, 包括移动设备, Android,iOS,Pad, 微信, 微博, QQ,web, 各自浏览器, 物联网设备等等......
第 2 层: API 网关: 包括服务注册, 发现, 认证授权, 单点登录, 熔断, 限流...... 网关的知识点丰富, 是微服务的核心之一.
假如网关对外提供统一的地址: www.jackyfei.com
第 3 层: 微服务集群: 包括各种具体的 microservice, 比如纵向划分的业务服务(用户服务, 订单服务,......), 横向划分的基础或公共服务(元数据服务, 公共服务......)
其他微服务的地址可能是这样的:
用户服务: 1.user.jackyfei.com
订单服务: 2.order.jackyfei.com
元数据服务: 3.base.jackyfei.com
消息服务: 4.msg.jackyfei.com
第 4 层: 事件总线: Event Bus 目的是消息解耦, 不要让服务之间直接的链接. 不同与 SOA 的服务总线, 事件总线相对比较轻量, 经常基于消息队列引擎进行解耦, 目的是为了让服务之间的关联弱化, 不直接进行关联. 很多时候用的是相对稳定, 可靠, 企业级的 RabbitMQ.
微服务的架构其实不难, 根据以上的架构, 每种业务都可以进行套用, 这里的难点在于服务的划分和粒度控制, 另外如何管理膨胀的服务是一个麻烦事.
三, 何时采用微服务?
1, 杨波说
这里引用架构师杨波 (前 Ebay 架构师, 目前任职拍拍贷研发部总监, 资深技术架构师, 微服务技术专家) 的一些观点:
" 企业一开始不推荐直接使用微服务, 因为微服务需要前期基础设施的投资, 复杂性很高, 如果对问题领域并不是很理解, 一开始用微服务, 你很难去划分服务的边界, 你的生产力反而会比较低, 而且你花了很大精力进行开发, 你的产品并没有被市场验证过, 有可能会失败, 所以这个选项风险会比较高. 所以我们推荐的是单块优先, 先从单块运用做起, 这样成本低, 团队成员也比较少, 无须太多研发投入, 就可以交付一些基本的功能给客户使用.
随着应用越来越成功, 客户增加, 你的系统复杂度会越来越高, 就会出现单块应用和团队规模之间的矛盾, 生产力会随着业务复杂度逐渐降低. 所以在一些初创型公司, 你更多看到的是单块应用, 只有一些中大型的公司会看到微服务架构."
" 交叉点表明, 业务已经到达了一定的复杂性, 单块应用已经无法满足业务增长的需要, 研发效率开始下降了, 而微服务可以提升研发和交付的效率. 这个点需要架构师去综合, 权衡. 个人经验, 一般团队需要达到百人规模, 才去考虑微服务."以上的观点讲的很中肯, 给我的启发和帮助非常大. 这里的交叉点怎么来确定和评估是重点, 比如我们上线一个社交姑且叫抖信, 初期为了快速上线, 验证可行性, 可以只开发首页聊天, 通讯录, 评论等基本功能. 产品上线后, 经过一段时间的运营, 用户开始逐步增多, 可行性验证通过, 下一阶段就需要进一步增加更多的新特性来吸引更多的目标用户, 比如再给这个社交抖信添加朋友圈, 消息通知, 游戏, 电商等等功能." 一般情况下, 这个时候就需要大规模地扩张开发人员, 以支撑多个功能的开发. 如果这个时候继续采用单体应用架构, 多个功能模块混杂在一起开发, 测试和部署的话, 就会导致不同功能之间相互影响, 一次打包部署需要所有的功能都测试 OK 才能上线.
不仅如此, 多个功能模块混部在一起, 对线上服务的稳定性也是个巨大的挑战. 比如 A 开发的一个功能由于代码编写考虑不够全面, 上线后产生了内存泄漏, 运行一段时间后进程异常退出, 那么部署在这个服务池中的所有功能都不可访问.
根据我的实际项目经验, 一旦单体应用同时进行开发的人员超过 10 人, 就会遇到上面的问题, 这个时候就该考虑进行服务化拆分了."--- 胡忠想(微博微服务技术专家)
至此, 我们何时采用微服务已经十分明确了, 关键是业务复杂度和团队规模两大要点, 而业务复杂度和市场窗口是权衡和抉择的首要因素.
2, 微服务落地条件评估
一般情况下, 业务系统引入新技术就必然会带来架构的复杂度提升, 在具体决策前, 你先要认识到新架构会带来哪些新的问题, 这些问题你和你的团队是否能够解决? 如何解决? 是自己投入人力建设, 还是采用业界开源方案? 假如你和我一样都是微服务的旁观者或者学习者, 那么下面的评估也许对你又所参考.
1 落地方式选择
不同的落地方式决定不同的资源配置.
方式一: 借力外部架构咨询公司提供架构 DEMO 和培训服务助推内部团队技术转型升级.
方式二: 招聘相关经验丰富的人员进来, 自行研究和搭建架构并做内部培训, 推动团队技术升级.
建议: 如果比较紧急, 采用第一种方式, 因为招聘匹配的人才比较困难, 等不起. 但是不管是那种方式, 对于团队来说都需要一定的技术人才储备方便后续交接和运维.
2 人才储备
这里分成两类人员, 一类是研究型, 一类是应用型. 研究型主要是以技术攻坚为主, 负责微服务的核心组件的研究和开发, 比如服务发布和订阅, 服务跟踪和监控, 服务的治理; 应用型主要是负责技术理解应用为主.
image
3 技术储备
微服务相关技术栈和微服务周边技术栈. 周边技术栈包括领域驱动涉及, 持续交付, 分布式至少, 负载均衡, CAP 理论, 缓存原理, DevOps 和容器化技术.
4 团队规模评估
杨波在给微服务的开发团队规划时候给了一个百人左右的大概预估, 至于到底需要多少开发人员就没有细说, 可能作者本身呆过的公司都是大厂, 对人力成本控制没有那么大的包袱, 对于中小企业, 人力是最贵的成本. 如果要一定要上微服务, 该怎么办?
对于微服务的团队规模众说纷纭, 有的说要百来号人; 有的说需要精兵 10 人左右; 有的说和人数没有关系, 只和业务有关; 有的说一个懂微服务的架构师也能搞定. 这些说法都比较笼统, 如果你想上微服务, 人力评估包括人力, 能力, 人数等等, 这些因素还是非常重要的, 毕竟成本才是商业的本质, 有可能不客观的规划会导致项目的溃败.
对于微服务的团队规模是哪些方面决定的呢? 我觉得至少要从以下两个维度来评估:
业务规模: 如果你们的业务架构非常复杂, 有仓储系统开发, ERP 系统, OA 系统, 订单系统等等, 业务越多, 需求人数越多(这里人数指的都是后台开发人数).
技术能力: 另外, 别忘了非功能性的开发, 比如 API 网关, 服务跟踪, 治理等也是需要人去开发和维护的, 这些非功能性的核心组件需要多少人, 由于没有完整的开发经验, 加上个别组件, 比如跟踪系统, 开发的程度可深可浅, 开发周期可长可短, 以目前个人的经验还无法给与合理的建议. 可能牛人 1 个人两周就够了, 也可能高级开发 2 个人, 一人分工三个核心组件, 两周也够用. 或者架构外包, 只要交接的人能跟上, 也是一种解决方案.
总结: 1 个精通微服务落地经验的架构师是必不可少的, 围绕架构师周边一帮高级开发, 按根据实际业务来确定, 一般一个开发负责 2-3 个核心模块, 不宜太多, 比如目前核心模块有 8 个, 对应人数配置大概在 3-4 个左右.
3, 转微服务风险评估
1 重写面广
由于是架构级别的调整, 之前能保留下来的大部分是解耦比较好的代码, 比如前端代码, 采集服务代码, 部分业务逻辑代码, 所以对现有框架冲击面比较大.
2 复杂度高
因为微服务是一种观念和思想, 又是新近技术, 本身就有各种架构实现方式和技术解决方案. 所以对技术人员来说, 对比选型本身就是一个考验. 加上本身涉及的技术面就比较广, 所以复杂度和门槛相对比较高.
但是该技术发源于亚马逊, 经过近些年的发展, 虽然还在发展, 但是已经相对成熟.
3 人员配置
微服务架构工作量主要集中在后端, 对后端开发人员的技术级别有较高的要求, 主要是对微服务原理和开源组件的熟悉上, 同时需要具备整体的微服务的意识. 暂时不具备整体微服务开发意识和经验, 需要通过培训后进行转型升级.
4 合作方式
如果采用借助外部架构力量来助推架构升级, 和架构单位的合作就不是简单的外包, 涉及的面会变得比较广, 在完全交接过来之前, 周期会比较长. 包括对我们业务架构的深入了解, 然后根据业务架构绘制可靠技术架构蓝图, 再根据技术蓝图进行落地实施(不建议只提供架构方案而由其他单位实施落地), 包括新系统的开发, 旧系统的升级, 当然这种升级是平滑过度的, 对业务窗口并不会产生影响.
4, 合理的拆分姿势
如何正确拆分? 这里正确指的是合理, 因为没有绝对的标准. 按照前人的经验可以分为纵向和横向两种划分方法:
1 纵向拆分
是从业务维度进行拆分. 标准是按照业务的关联程度来决定, 关联比较密切的业务适合拆分为一个微服务, 而功能相对比较独立的业务适合单独拆分为一个微服务, 比如上图中的订单服务, 用户服务. 另外粒度太小, 服务聚合是一个坑, 粒度太大, 分和没分一个样.
2 横向拆分
是从公共且独立功能维度拆分. 标准是按照是否有公共的被多个其他服务调用, 且依赖的资源独立不与其他业务耦合. 比如上图中的元数据服务和消息服务.
3 总结
借用《微服务设计》中的一句话:"你越不了解一个领域, 为服务找到合适的界限上下文就越难...... 服务的界限划分错误, 可能会导致不得不频繁地更改服务间的协作, 而这种更改成本更高......"
四, SOA 和微服务
由于 SOA 和微服务有千丝万缕的关系, 这里简单罗列双方的对比图, 算是一个小知识点:
两种架构背后的意图是不同的: SOA 尝试将应用集成, 一般采用中央管理模式来确保各应用能够交互运作. 微服务尝试部署新功能, 快速有效地扩展开发团队. 它着重于分散管理, 代码再利用与自动化执行.
五, 总结
最后让我们回顾一下前人经典的话语:
分布式第一定律是 "尽量不要使用分布式".
软件行业从业者, 尤其是那些已经不写代码的从业者, 总会期望有银弹, 但银弹终究是没有的.
微服务依赖于 "基础设施自动化". 微服务不是 "银弹".
还是回到我们架构设计的原则上, 遵循简单, 适用, 演化的原则, 那么你的抉择也许会变得没有那么令人纠缠.
来源: http://www.jianshu.com/p/ebd32ea3e46f