刷爆硅谷的四条微服务军规

《刷爆硅谷的四条微服务军规》要点：
本文介绍了刷爆硅谷的四条微服务军规，希望对您有用。如果有疑问，可以联系我们。

当下,微服务是一个炙手可热的跨时代架构.跟进这个新趋势,就意味着你得处理旧应用.尤其在大型组织,鸡蛋不会只放在一种架构篮子里.

企业对微服务的兴趣渐渐高涨,就好像技术行业的任何正向趋势.话说到这里,其实我想说更重要的是：请保持对事物前景的透视.虽然微服务已经是“今天的事”,但是你不能只针对这个特定的趋势做优化.除非你是一个小初创公司,实在没有富余资源来做投入,否则可能要在以后支持成本更高的混合流程.

微服务最大亮点之一：不用局限在单一的发布周期来对系统一个或多个部分打补丁做优化,也不必把所有内容都部署在一起.如果你想优化一段代码或纠正错误,就像在用单片应用程序那样,不必等到下一个发布周期.

貌似看起来很高端,对不对?

然而,微服务方法并不是所有软件开发和交付的灵丹妙药.除非你有点厉害,对基本所有的问题了如指掌,否则光是报错就足够让你怀疑人生.

下面是我给到的四点建议,希望能帮你避开大坑,用好微服务.

1. 代码之前请先分解数据

用微服务,你把整体应用分成不同服务以便完成不同任务.电商类应用就是个方便贯彻微服务拆分思想的好例子：用户登录,浏览产品,看到建议(详情、评价等),添加购物车、下单、付款.

如果计划将现有单片应用迁移成微服务体系结构,则需要对系统以及所有服务如何对接与交互有深入的了解,避免分解过程中误判而做了无用功.要知道,你对数据库模式做出的决定,无论是要为每个服务设置单独的数据库,还是对每个服务设置专用表 ,甚至使用外键执行的操作,都会对开销、总体和成本产生直接影响.

所以这块我的建议是：分解代码之前,先分解数据.

2. 还不是大巨人,那就先做小巨人

如果你的微服务改造从一张白纸开始,从一个空白新应用的一小块开始.首先,你得弄清它涉及的域的样子以及存在什么类型的数据关系?你在处理事务数据还是关系数据?这些答案将对数据结构产生很大影响.

对于微服务,大多数从业者需要更好地自动化部署管道,从代码检入到生产,并且更好地监控环境.你可能看到某个服务有个问题,但很可能实际上是另一个问题在上游的症状.在这种情况下,就需要有自动化过程来回滚动服务,或者说在新旧版本之间做切换.

在将应用程序重构到微服务之前,得先了解依赖关系.

3. 注意服务间的通信

服务虚拟化和服务间通信也会导致大问题.微服务一个重要的考量标准是拥有定义良好的公共API,方便探查以及每个微服务做交互.它不care开发人员是否用了REST、HTTP或JSON,而更在于知道它们如何用协议来启用强大的服务间通信.毕竟如果服务之间的呼叫由于接口设计不当而延迟或中断,那这故事说起来可就长了.

微服务通常倾向于部署在容器中,因为容器提供隔离,容易设置或删除,并且只运行一个进程.它们还具有比虚拟机更小的占用空间,因此资源利用率具有相对显着的差异.

但是如果你有100个服务在100个容器中运行,你就要从运营和管理角度看待事物.首先部署会变得更复杂,而且诸如监视,日志记录和修复动作会变得越来越重要.

4. 做一把好菜刀的充分条件

俗话说,好钢用在刀刃上.改造应用,粗浅技术执行起来肯定困难重重,你要确保的是,既然想做一把好菜刀,那你就得有好钢好手艺.

微服务允许你为每个服务选择完全不同的技术栈.你可以用Java做这个微服务,用PHP做那个微服务,这个用静态内容,那个用Apache…随便你,微服务允许你这样选择.也就是说,你就能以更小,更独立的团队来处理单个服务.只要分解得当,理论上你的IT管理能力永远足够你所能接手的项目.每个团队可以在独立发布的生命周期上工作,不会受到分发影响.

大规模运行容器和微服务还需要许多目前在组织中还没普及开的多学科技能,它和曾经的单一应用开发思维完全不同.在技术和文化层面,熟悉DevOps和持续交付的最佳实践非常重要.

正好,我们本就应该抱着“活到老学到老”的积极态度面对这个缤纷的世界,对吧?

原文来自微信公众号：DevOps研究院

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4303.html