easthomeRT 发表于 2018-9-3 17:02:14

【干货分享】基于微服务架构的爱恨情仇



本文来自“”微服务不是免费的午餐”文章的摘录。
当今市场瞬息万变,软件为了适应动态市场的需要就需要增加产品发布的频率,有时会是一天发布多次。另外,随着软件产品的同质化竞争,终端用户对应用的易用性要求越来越高,对任何宕机采取零容忍的态度。当下基于云服务能力,软件的可扩展性和高可用性的需求也变成了一种常态需求,微服务的概念和应用实践更被推到了软件部署的风口浪尖。
所谓微服务就是一种架构模式,我们可以把它作为传统基于面向服务架构(SOA)的一种变体。微服务提倡将单一应用程序划分成一组小的服务,而服务之间可以互相协调和互相配合,共同为终端用户提供必要的产品使用价值。每个服务运行在其独立的进程中,服务与服务之间采用轻量级的通信机制互相沟通(通常是基于HTTP 的RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境和类生产环境等。对具体的一个服务而言,应根据系统上下文,选择合适的语言和工具对其进行构建。

微服务架构是相对于传统开发的单体式架构(Monolithic Architecture)而言的。单体式架构也称巨石型架构,是所有功能或组件都打包在一起进行发布,此发布包通常包含数据输入/输出、数据处理、业务实现、错误处理、前端显示等所有逻辑。这样的发布方式就很少有外部软件的依赖,说明单体式架构也是有优点的,比如开发团队的组织架构简单,便于集中式管理,避免重复开发的问题。并且,所有功能都集中在本地,不存在分布式的管理和调用损耗。但是这个架构的缺点也是很明显的,比如开发人员更新代码会受到彼此限制,经常需要相互等待对方的功能更新,代码入库时的冲突不断,造成极高的开发成本。另外,维护难,各个模块的代码都耦合在一起,没有经验的新人不知道从何下手,而一旦出现软件Bug,就需要大改。并且构建(Build)时间过长,任何一个小量级的修改,都要重构整个项目,编译非常耗时。还有一个缺点就是稳定性差,一个微小的问题,都可能导致整个进程崩溃,使得整个应用程序无法工作。扩展性不够也是一个缺点,难以分布式部署和扩容,无法满足高并发下的业务需求。而且,一旦业务范围扩展或者需求有所变化,就难以复用原有的服务,必须重新开发。

单体式架构一般适用于企业刚起步时,业务规模小,开发团队规模也小,所以通常开发出来的系统是单块的。随着业务的扩大,团队规模也会随之扩大,这个时候多团队组织架构和单块系统架构之间就会产生不匹配问题(沟通协调成本增加,交付效率低下等等)。如果不对单块架构进行解耦和调整以适应新的团队沟通结构,就会制约组织生产力和创新速度。把单块架构按照业务和团队边界进行拆分,重新调整为模块化分散式架构(微服务架构是一种方案),那么组织团队沟通结构和系统架构之间又能匹配起来,各个团队才能够独立自治地演化各自的子系统(微服务),这种架构的解耦和调整可以解放组织生产力和提升创新速度。

微服务架构的优点和缺点都很明显。
优点是:1、部署、回滚变得更快、更简便;2、每个服务都可以单独扩容。在需要发布新功能时,可以用插件的形式添加到系统中而不需要重新部署整个系统。3、提供据接口集成,而不是以数据库的方式同其他服务集成。
缺点是:1、增加了不同团队之间交流成本的提高;2、基于微服务架构的分布式系统的测试和管理复杂度大幅度提高;3、分布式部署会给团队的DevOps 能力提出更高的要求。
由此我们可以想见,微服务是个很好的架构,加速了持续集成和持续部署的实现方式,前提是你的团队已经具备很想的DevOps实践能力和沟通协作要求。我们不能不对微服务产生爱之深,恨之切的想法。
东方瑞通成立于1998年,总部在北京,分别在上海、广州、天津、武汉、济南、深圳、成都、重庆、杭州和西安建立了直营分部,全国拥有超过40间专业培训教室、40多位专职讲师及180多位签约讲师;作为国内企业级IT高级技术&管理培训的领军机构,为数千家企业客户提供员工外派(公开课)和团体定制培训服务,累计培训专业人才数十万名。


残混。 发表于 2021-8-7 15:37:46

通俗
页: [1]
查看完整版本: 【干货分享】基于微服务架构的爱恨情仇