中台战略和微服务
随着企业业务的发展,系统变得越加复杂,已经影响到了企业的发展速度,这就需要中台和微服务了。系统越复杂,微服务带来的收益就越大。
中台
在传统的“前台---后台”架构中,各个项目相对独立,许多项目都在重复发明同样的轮子,既让项目本身越来越臃肿,也让开发效率越来越低。这时候为了提高开发效率,我们有必要整合出一个中间组织,
为所有的项目提供一些公共资源。而这个中间组织,就是人们所说的“中台”。
中台大概可以划分为业务中台、数据中台、算法中台、技术中台、研发中台、组织中台和字典中台,其中数据中台通过API的方式提供数据服务。
业务中台包括支付中心、商品中心、营销中心、搜索中心、用户中心和交易中心。
数据中台包括数据建模、日志数据和用户图像。
算法中台包括语音识别、图像识别、搜索算法、推荐算法、人机对话和垃圾过滤。
中台的本质是共性服务与资源的有效复用,概括为四个字——服务复用。
在集团公司内部,找到共性业务或需求,最好是有较多的内部共性业务和需求。新的业务类型和之前的业务相似度很大时,就需要考虑通过中台的方式来支撑了。
中台和微服务的关系?
中台是企业级能力的复用,也是一种方法论——企业治理思想。
微服务是可独立开发、维护和部署的小型业务单元,是一种技术架构方式。
中台并不是微服务,中台是一种企业治理思想和方法论,微服务是技术架构方式,中台是公司CEO和COO管理层要考虑的,微服务是技术架构师要考虑的。
在谈中台时需要先考虑业务模块如何划分以及服务如何识别,而实现技术是微服务。而谈微服务时本身就是技术实现和架构方法,是否一定用于中台需视情况而定。
中台强调横向拆分和分层,微服务强调纵向拆分和解耦。中台的构建不一定采用微服务,也可以采用传统的IT架构进行构建,只要满足共性业务能力下沉要求即可。
数据中台构建本身不能按微服务思路做。中台构建可以用微服务,前台应用构建同样可以采用微服务。
中台强调能力开放,微服务虽然不强调共性能力开放,但提供API网关进行能力开放。
中台化的落地,需要使用微服务架构。中台强调核心基础能力的建设,基础能力以原子服务的形式来建设,并通过将原子服务产品化,支撑业务端各种场景的快速迭代和创新。
原子服务和微服务所倡导的服务自闭环思想不谋而合,使微服务成为实现原子服务的合适架构。
支撑业务场景的应用也是通过微服务来实现的,其生命周期随业务变化需要非常灵活的调整,这也和微服务强调的快速迭代高度一致,所以业务应用服务也适合通过微服务来实现。
中台化系统建设不是一蹴而就的,需要长期动态地演进,加上其技术体系已经在互联网领域被证明且相当成熟,中台在企业落地、执行的土壤已经完备。
微服务和API的关系?
微服务和API是不同的东西,就像微服务和容器也不是同一种东西一样。微服务通常依赖API作为与语言无关的通信手段,以便在内部网络中相互通信。
开发团队可以使用相似的方法和工具来创建公开API和微服务API。