如何实施微服务?
这是在准备采用微服务之前需要考虑的问题,如果你也有和我一样的需求(不熟悉微服务或者使用微服务之前考虑事宜),可以参考一下这篇文章.
此文章内容非出自本人,而是出自翟永超的<<SpringCloud微服务实战>>(有兴趣的朋友可以留言或者去搜索,网上挺多资源的),都是本人的总结以及一些理解,或许会有异议,但是源头都是来自书中,对于初期或者在玩微服务的朋友来说,这本书绝对是本好书........
本人不生产,只是搬运工...
什么是微服务?这里不做解析,有什么问题可以留言.
一.缺点
1.运维新挑战:
因为微服务都是独立运行的,有些甚至是运行在不同的平台,并且业务发展快速,服务成倍增加,要让这些服务有条不紊的组织,编排起来不是一件容易的事情,需要运维人员有更多的新技能来应对这些事情.
2.接口一致性:
虽然我们将服务都拆分成了无数个独立的接口,但是业务上的依赖依然存在,所以在两个服务修改起来需要双方的互相协调,需要更加完善的接口和版本管理,或是严格遵循开闭原则.
3.分布式的复杂性:
由于拆分之后的服务存在于各个独立的进程中,他们之间的协作是靠通信进行的,所以分布式环境的问题是系统设计的一个大问题,比如网络延迟,分布式事务,异步消息等都将是一个极大的挑战.
二,特征
1.组件化
每一个服务都已经拆分,都是独立开发,独立部署,互相不会影响.摆脱传统修改其中一个接口需要整体部署.
2.按照业务组织团队
单体应用中,如果需要在页面添加一个字段,那么修改的部门有DBA,运维,后端,前段,设计师等,虽然修改的都是极小的内容,但是内耗(部门协调以及耗时)却是非常大的.所以建议按照业务组织团队,
提升开发效率以及更好的把控团队.
3.做产品的态度
这个就见仁见智了,因为有很多时候业务中发生的特殊或者异常问题,项目经理或者产品经理都并不知晓,但是程序员却很容易就发现的需求,需要他们提出来一起去完善项目.
对程序员的有一定的要求,要求每一个程序员都要有做产品的态度,而不是为了交付或者完成开发的态度.
4.智能端点和哑管道
这个其实我不是非常理解,原文如下:
5.去中心化处理
简单的来说,各个服务之间需要轻量级的契约定义接口,可以根据各个服务的业务特点采用更加好的技术去服务,如日志方面的可以用MongoDB,用户信息却用Redis等等...
6.去中心化处理数据
我们都希望将各个服务都有自己的数据库,让数据更加细致化,但是这样就会带来一个问题.数据一致性,所以更加强调服务之间"无事务"调用,而对于一致性,则只要求最终一致即可,如发生错,需要
通过补偿机制去处理,使得错误数据最终到到达一致.
7.基础设施自动化
由于拆分的原因,在业务疯狂发展的现在,服务基本成倍的增加,对于运维来说,这将是一个噩梦,所以我们需要自动化测试以及自动化部署.
8.容错设计
在微服务中,为了避免故障蔓延,我们需要一套较为完善的日志监控组件,每一个服务中我们都需要实时的关键数据,如网络延迟,吞吐量,断路器状态,服务状态等等.才能快速的检测出问题.
9.演进式设计
这个的话比较见仁见智,我直接上原文吧,原文:
原创文章,转载需注明出处,谢谢.