微服务

传统开发中的景象

程序员们日以继夜,诠释着披星戴月的含义,却不断的沉沦在重复搭建环境、重复系统部署、重复环境验证、重复代码开发等等的炼狱之中,“感觉身体被掏空”的绝望如影随形。
大型软件项目已成为大量代码的随机而无序的堆积。工程师一旦完成项目,就恐避之不及,不愿再去碰自己几个月来夜以继日的劳动成果。

Restful

REST — REpresentational State Transfer 表现层状态转移,是一种架构风格,不是技术体系。
URL定位资源,用HTTP动词(GET,POST,DELETE,PUT)描述操作。
即通过HTTP动词来实现资源的状态扭转:

  • GET 获取资源
  • POST 新建资源(也可用于更新资源)
  • PUT 更新资源
  • DELETE 删除资源,有的业务系统中,删除只做逻辑删除,即只设置资源为已删除状态。

GET、PUT、DELETE操作是幂等的,安全和幂等的意义在于:当某个操作没有达到预期的目标时,我们可以不停的重试这个操作,而不会对资源产生副作用。
创建操作可以使用POST,也可以使用PUT,区别在于POST是作用在一个集合资源之上的(/uri),而PUT操作是作用在一个具体资源之上的(/uri/xxx),可以理解为,如果URL可以在客户端确定那么就使用PUT,如果是在服务端确定那么就使用POST。
现在也有的设计只用GET和POST,把具体操作写在uri中。

幂等

在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数是指可以使用相同参数重复执行,并能获得相同结果的函数。这些函数不会影响系统状态,也不用担心重复执行会对系统造成改变。例如,“setTrue()”函数就是一个幂等函数,无论多少次执行其结果都是一样的。

CAP理论

任何分布式系统在一致性、可用性、分区容错性三方面不能兼得,最多得其二,因此任何分布式系统的设计只是在三者中的不同取舍。
Consistency(一致性):所有节点上数据时刻同步
Availability(可用性):在一定时间能响应客户端的请求
Partition tolerance(分区容错):允许出现网络分区

分区

分区是指网络分区,分布式系统中各节点不再连通。一个分布式系统里面,节点组成的网络本来应该是连通的。然而可能因为一些故障,使得有些节点之间不连通了,整个网络就分成了几块区域,数据就散布在了这些不连通的区域中。
当一个数据项只在一个节点中保存,那么分区出现后,和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。提高分区容忍性的办法就是一个数据项复制到多个节点上。
然而,把数据复制到多个节点会带来一致性的问题。要保证一致,每次写操作就都要等待全部节点写成功,而这等待又会带来可用性的问题。
总的来说就是,数据存在的节点越多,分区容忍性越高,但要复制更新的数据就越多,一致性就越难保证。为了保证一致性,更新所有节点数据所需要的时间就越长,可用性就会降低。
实际上这在分布式系统中一般认为P是必须的,所以AC需要权衡。
满足AC意味着网络分区不能发生;而当存在网络分区时,将不再同时保证AC。有一个等价的理论:在一个不可靠的分布式环境中,无法同时满足活性(A)和安全性(C)。

微服务实践

服务拆分原则:
横向拆分。按照不同的业务域进行拆分,形成独立的业务领域微服务集群。
纵向拆分。把一个业务功能里的不同模块或者组件进行拆分。把公共组件拆分成独立的原子服务,下沉到底层,形成相对独立的原子服务层。
做好微服务的分层:梳理和抽取核心应用、公共应用,作为独立的服务下沉到核心和公共能力层,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。
微服务的拆分力度需与具体业务相结合,总的原则是服务内部高内聚,服务之间低耦合。

微服务vs传统开发:
部署方式不同,微服务自动化运维不可不上。

中小型互联网公司微服务实践-经验和教训
http://www.ityouknow.com/springcloud/2017/10/19/micro-service-practice.html

如何解决微服务架构中的身份验证问题?
http://mt.sohu.com/20161221/n476556655.shtml

模块化与微服务

正确的组织方式是:独立出来各个业务无关功能的静态模块或动态服务,方便各项目的各子系统快速集成。包括:短信发送功能,数据库模块,权限验证功能,公共方法模块等。保持模块功能单一性,使工程不引入无关的功能模块。
阿里云中也提供收费的短信发送服务。
独立服务不会出现包冲突,独立模块不用单独部署服务。微服务是加强了的模块化。
最终策略:优先使用Maven模块化组合,当模块化不能满足时,再升级模块为微服务。

模块化还是微服务 – 为什么说大部分团队微服务化都走入了陷阱
http://www.sohu.com/a/149458799_256833

当系统需要提升处理能力时,可选择重置扩展架构和水平扩展架构,

心得:
微服务架构,需要每个人完整完善的完成相关服务。
不同的语言和开发环境对编码过程中的严谨程度要求不一样。
前后端分离,要根据数据存储特点,数据传输效率定义接口。
在编码前要有充分反复的需求分析、开发设计和程序设计。
不要过度设计,利用程序自动化,减少和局部化手工工作,减少代码重复冗余。
注明采用特殊设计或特殊编码方式的原因。
不要留下设计和技术债务。