运维公会：正向代理和反向代理
1、正向代理
（1）服务对象不同
正向代理服务器的服务对象是客户端，可以将客户端和代理服务器看作一个整体。
（2）配置方法不同
需要在客户端配置代理服务器的地址
（3）作用
当客户端没有办法和服务器直接进行通信的时候，这个时候使用代理服务器是让客户端和服务端通信的好方法。客户端指定请求给代理服务器，代理服务器将请求发送给服务端，将服务端的内容取来，返给客户端。这样完成客户端和服务端的访问。
2、反向代理
（1）服务对象
反向代理服务器的服务对象是服务端，可以将服务端和代理服务器看作一个整体。
（2）配置方法
代理服务器上要配置上服务端的地址。
（3）作用
可以保证内网的安全，客户端没有办法直接和服务端进行通信，当客户端的请求直接发送给代理服务器，代理服务器去取过服务端的内容，返回给客户端。还有就是做负载均衡，这个是用的最多的，可以保证网站的高并发，高可用性。
假设我们要拆分出来一个微服务叫“client-service”，它需要访问“core client”表。第一步，我们先把程序从原来的代码里拆分出来，变成一个服务. 数据库不动，这个服务仍然指向原来的数据库。其他程序不再直接访问这个服务管理的表，而是通过服务调用或另建共享表来获取数据。
图片来源
第二步，再把服务的数据库表拆分出来，这时微服务就拥有它自己的数据库了，而不再需要原来的共享数据库了。这时就成了一个真正意义上的的微服务。
上面只讲了拆分一个微服务，如果有多个需要拆分，则需一个一个按照上面讲的方法依次进行。
另外，Martin Fowler在他的文章"Break Monolith into Microservices"里有一个很好的建议。那就是，当你把服务从单体程序里拆分时，不要只想着把代码拆分出来。因为现在的需求可能已经跟原来有所不同，原先的设计可能也不太适用了。而且，技术也已更新，代码也要作相应的改造。更好的办法是重写原来的功能（而不是重写原来的代码），把重点放在拆分业务功能上，而不是拆分代码上，用新的设计和技术来实现这个业务功能。
数据库设计是微服务设计的一个关键点，基本原则是每个微服务都有自己单独的数据库，而且只有微服务本身可以访问这个数据库。微服务之间的数据共享可以通过服务调用，或者主、从表的方式实现。在共享数据时，要找到合适的同步方式。在微服务架构中，数据库的修改影响广泛，需要保证这种修改是向后兼容的。实现跨服务事物的标准方法是Saga。当把单体程序拆分成微服务时，可以分步进行，以减少对现有程序的影响。
原文：https://www.cnblogs.com/dakunqq/p/11703084.html