企业自由开发团队实践微服务架构如果企业本身的IT成熟度没有达到一定阶段,显然是不可能推行实施微服务架构的。在了解了微服务架构后,我们来分析下微服务架构又哪些缺点和难点,互联网企业为何适合做微服务架构,其重要的一个原因就是互联网企业如电商平台,在进行了微服务化后各个模块之间耦合性很低,并不会有太多的集成和协同点。
1、企业微信可以给企业带来哪些好处?
我们企业是使用企业微信的,很高兴分享给大家。第一个带来的好处是,你可以随时找到你需要联系人员的联系方式,企业微信是实名制,上面有整个企业人员的联系方式,可以随时联系你需要的人,不用再为找不到人员的联系方式而苦恼,第二个好处是,企业微信有信息已读功能,你发的信息,对方有没有看,一目了然,再也不用为担心对方有没有看到信息二担心,也让那些故意潜水的同事无处可逃,提高工作效率,避免拖沓。
2、系统软件架构中,现在很流行微服务,那么使用微服务就一定好么?微服务有哪些缺点呢?
下面简单回答下这个问题,在回答这个问题前还是先回顾下微服务架构。微服务架构概述微服务架构本质是单个业务系统彻底的组件化(前端,逻辑层,数据库)解耦,同时相互之间通过轻量的服务接口和协议进行协同,这和很早就谈到的组件化架构思想是一致的,实现微服务架构后,你会看到没有传统业务系统的概念了,有的只是微服务模块或小应用。
微服务架构最近又炒的相当活,很多人会说SOA过时了,ESB过时了,甚至还有人用微服务架构去彻底的否定SOA和ESB,这些都是相当危险的信号,在我12,13年写企业私有云PaaS平台的一系列文章的时候,已经提出了业务能力组件化,组件服务化的微服务架构思想,但是实际应用实施效果并不太理想。我们可以先看下从单体应用到微服务架构的变化图,
把这个核心搞清楚后,再来看下网上找到的对微服务架构的一些定义和阐述:微服务可以在“自己的程序”中运行,并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行,通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中,许多服务都可以被内部独立进程所限制,
如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程,微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称,微服务是需要与业务能力相匹配,这种说法完全正确,不幸的是,仍然意味着,如果能力模型粒度的设计是错误的,那么,我们就必须付出很多代价。
如果你阅读了Fowler的整篇文章,你会发现,其中的指导建议是非常实用的,在决定将所有组件组合到一起时,开发人员需要非常确信这些组件都会有所改变,并且规模也会发生变化。服务粒度越粗,就越难以符合规定原则,服务粒度越细,就越能够灵活地降低变化和负载所带来的影响。然而,利弊之间的权衡过程是非常复杂的,我们要在配置和资金模型的基础上考虑到基础设施的成本问题,
在了解了微服务架构后,我们来分析下微服务架构又哪些缺点和难点。微服务模块拆分后,各微服务间集成复杂度指数级增加简单举例来说,一个企业已经实施了5个业务系统,业务系统之间有10个接口,如果全部微服务化则可能设计到50个微服务模块,上100个接口和集成点。可想而知,在彻底实施微服务后,我们前期架构设计,后期集成和管控的复杂度增加10倍以上,
这种集成难度会远超大多数人想象,如果拿真实做的项目来说,如果谈业务系统只有3个,而到微服务模块级别则有接近60个,而实际涉及到的集成接口上1000个。我们做任何一个复杂端到端业务的联调基本就需要花2,3周甚至更长的时间,互联网企业为何适合做微服务架构,其重要的一个原因就是互联网企业如电商平台,在进行了微服务化后各个模块之间耦合性很低,并不会有太多的集成和协同点。