概览
“微服务”是一个非常广泛的话题,在过去几年里,市面上存在着各种不同的定义。
虽然对这种架构方式没有一个非常精确的定义,但仍然有一些概念具有代表性。
微服务有着许多围绕业务能力、自动化部署、终端智能化、分布式数据以及其他与团队相关的一些特性。
为了更好地说明,我们参考了Martin Fowler对微服务简单而具体的定义:
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
GeneXus智能软件开发平台,已经能够并将继续支持软件解决方案背后的各种技术架构体系。
要理解什么时候使用微服务架构能够满足业务软件解决方案,首先必须明白微服务架构,并不仅仅是对团队技术层面的一个挑战,同时也是关于开发和交付软件层面的一个全新理念。根据康威定律(Conway’s Law),拥有完整发团队的公司才能构建完整统一的解决方案。
一个公司应该在成熟度较高的时候再采用微服务架构。即使像亚马逊、Facebook、Netflix、Uber等这些公司,也都是在解决了人才和技术等相关扩展性的问题后,才采用了微服务架构。
但不管如何,GeneXus 16以及后续的版本能够比其他任何平台帮助公司更容易得使用微服务架构。
接下来,我们看一下微服务架构主要会面临哪些特性和挑战。
为什么要使用微服务?
在UX、安全性和集成性等各种需求不断变化的大环境下,微服务的首要任务就是,保证我们正在开发的系统在需求变化的同时还能够轻应对。
因为在现实环境中,软件必须不断接受改变才能更具竞争力,同时还要聚焦于去适应各种业务场景。
■发布
基于微服务架构,我们并不需要发布所有的项目。只需要对涉及到的几个服务,根据它们的发布周期进行版本管理即可。
尤其是当你