我们将去往哪里？？？（上）

我们这个时代走过的技术发展线路：

OP——>OO——>SOA——>microservice——>Serveless。。。？

=====================面向人民币编程(原动力)=====================>

现在的IT界更新换代的速度连时尚界都自愧不如，没有一个整体的认识，往往容易陷入只见树木不见森林的境地，借以此文对现有的技术体系做一个小小的梳理。

面向过程，强调的是操作和数据的分离。但是，现实的时间往往不是线性的，这个时候就需要通过OOP来对非线性的现实进行建模。

OO==>SOA==>microservice，内核其实是一脉相承的===>构建high coheison 高内聚、loose coupling松耦合的类，系统，子系统。

High coheison:

  我见过的最精准的描述——the code that changes together, stays together.

Loos coupling:

 a picture is worth a thousand words.

 

OO的基石或者设计原则是经典的SOLID，我用自己的话再啰嗦一边。

Single responsity princple：只做一件事，并把这件事做好。===>高内聚，松耦合

Open close principle：对扩展开放，对修改关闭。===>松耦合

Liskov's Substitution Principl: 所有父类对象出现的地方都可以用子类对象代替。=>避免出现奇怪的错误。。。

Interfacde segretion: 不要依赖不需要的接口。和SRP，Demeter principal(只跟好朋友进行合适的沟通)的区别 =>decoupling 

Dependency inversion principle: =HollyWood principal：don't call me, we will call you => decoupling....

 

上面这些设计原则与设计模式是什么关系呢？无非是在特定的上下文环境下，对特定的问题可重复实施的，满足SOLId原则的解决方案。前文说了，我们的目标是高内聚，低耦合，那怎么把设计模式对应上呢？即如何解耦：encapsulation,abstract,中间层、基于接口而非实现编程、多用组合及依赖注入；还有各种设计模式支撑：工厂方法、策略、装饰、代理、模板方法、责任链、状态、适配器等等设计模式。

 

(微)服务和OOP的异同点在哪呢？我们其实可以这么通俗的看这个问题，(微)服务和OOP的组成单元是一样的，都是基于everything is object, 无非是单位的大小，我们甚至可以认为独立部署的pakcage就是一个具体的服务。但是服务和OO的区别在哪？最本质的还是进程内调用和IPC进程间调用（请自行baidu分布式系统的八大谬误），所以除了服务解耦外，还需要实时感知并能动态调整线上的服务====>服务治理。服务治理一个long topic，关键是design for failure，主要包括服务冗余消除single point failure，配套需要服务注册，发现，路由，负载均衡；服务容错：重试，幂等，限流，熔断，隔离，降级。那么就解耦这个topic而言，(微)服务和OOP有啥区别呢？

我的理解针对分布式可独立部署的微服务而言，耦合还体现在数据库的强耦合，服务间调用的临时耦合，服务建模的领域耦合。对应的解耦策略分别为分库，缓存/熔断，DTO。

to be continued...