这篇文章将为大家详细讲解有关SOA/微服务的要求和原则是什么，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
目前累计服务客户近1000家，积累了丰富的产品开发及服务经验。以网站设计水平和技术实力，树立企业形象，为客户提供成都做网站、网站制作、网站策划、网页设计、网络营销、VI设计、网站改版、漏洞修补等服务。创新互联公司始终以务实、诚信为根本，不断创新和提高建站品质，通过对领先技术的掌握、对创意设计的研究、对客户形象的视觉传递、对应用系统的结合，为客户提供更好的一站式互联网解决方案，携手广大客户，共同发展进步。
SOA思想的核心根据定义可以拆分为两个重要的内容，一个是根据业务建模和架构设计过程找寻到粗粒度的可重用的服务；其二是这些服务可以组合，可以组装和编排以满意业务流程的需求。前者重点对应的是ESB服务总线，而后者重点对应的BPM和BPEL相关业务能力。
按照优先顺序需要解决的问题：解耦，复用，编排，控制
一个完整的业务系统通过业务建模和架构分析应该根据松耦合的原则拆分为多个业务组件，业务组件最终转换为应用系统实现中的应用模块（服务组件+技术组件）。每一个组件都相对独立，都可以独立进行分析设计，开发，测试，部署和后续运维的管理。
解耦要做到彻底，不仅业务层进行组件拆分，底层数据源等也要完全拆分开。
组件对外提供的应该是服务，不应该是通道形式的CRUD。
服务本身就是轻量API，通信采用webservice，rest还是消息等其他方式并不重要，重要的是服务接口和契约不变。
服务的目的不仅仅是为了解决组件间的交互，这仅仅达到了服务能够松耦合各个组件的目的。而为了满足服务的可复用性，即需要考虑在各个业务模块的基础上，应该有一个更加底层的提供共性能力的基础公共模块，这个模块提供共享的可复用的服务能力出来。
技术组件：安全，消息，缓存，文件，日志，异常，流程引擎等。
组件划分的粒度需要详细设计，每个组件内聚的领域活动可能依赖多个服务，甚至其他组件。这时要保证组件之间不能混乱的交叉调用。业务流程的实现或复杂业务逻辑的实现应该体现服务组装或服务编排的思想。
组件领域活动内依赖的其他组件服务越少越好。
编排服务尽量避免分布式事务处理，需要考虑自行实现事务管理方案。
组件领域活动内不依赖该组件内的其他服务。
组件内服务之间保持独立性，避免业务重叠，一旦发现业务重叠重新考虑服务的设计。
一个业务系统内部可以选择实现一个最简单的服务总线，也叫做系统内部轻量ESB。
实现这个目的并不是为了UDDI统一的服务目录库。而是业务系统本身服务化后，组件之间会出现大量的服务消费和调用，一个业务系统需要对这些业务访问调用进行统一的管控，包括服务运行监控，安全和鉴权，统一服务地址等。这些是基本的需求。
当然没有真正意义上的服务总线也不要紧，一个业务系统服务化后，在一种标准的模块化服务架构下，是很容易的实施和接入到一个ESB上面的。这个并不是基于 SOA架构的业务系统的重点。包括现在的OSGI框架，也并不是完全的符合轻量ESB总线的要求。而对业务系统引入了更多在实现上的复杂性。
关于SOA/微服务的要求和原则是什么就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
