I have an general idea to do this:
1. We do not need to create a new port for this feature, and share the microservice port. It has same security constraints like REST api. 2. We can provide both ui and REST api for this feature. Provided we need to easily access the ui from edge service(Is this possible to do it easily?). 3. We can start a new project, e.g. servicecomb-admin (or a module like in edge service do), users start this admin service along with microservices. So they can access admin service easily, do not need to care much about security constraints like service center console. ------------------ ???????? ------------------ ??????: "willem.jiang"<willem.ji...@gmail.com>; ????????: 2019??3??5??(??????) ????2:12 ??????: "dev"<dev@servicecomb.apache.org>; ????: Re: [discuss][java-chassis] new feature for inspect internal statusof a microservice instance I think we can start from the instance troubleshooting solution first, then we can consider to let management console redirect the request to the certain instance. Willem Jiang Twitter: willemjiang Weibo: ????willem On Tue, Mar 5, 2019 at 11:54 AM wjm wjm <zzz...@gmail.com> wrote: > > @yaohai...@huawei.com <yaohai...@huawei.com> agree to you. > but > 1.graphical user interface is not a problem, network is a problem > browser maybe can not connect to the instance directly > 2.we must provide these features by governance console, the problem is if > we will provide it by instance also? > when provide by governance console, it's more powerful than by instance > because instance can only have self information, but governance can show > related instance's information. > > yhs0092 <yhs0...@163.com> ??2019??3??5?????? ????11:23?????? > > > Here is just my personal consideration. It's indeed a complex problem when > > get involved in security issues. > > > > > > Once we decide this function is only provided directly by the service > > instances, users can only log into the micro-service clusters to get access > > to these informations. In such case we can assume that the security should > > be guaranteed by users themselves. > > There are still several problems: > > 1. Usually there are all Linux OS servers in a cluster, with no graphical > > user interface. It may be hard to find a browser to read the informations. > > 2. If the instances enable Mutual TLS authentication, it may be difficult > > to get access to the informations directly. Or we can provide an isolated > > port for this feature, but it makes us further away from our security goal. > > > > > > If we provide a separate console service, maybe we can solve these > > problem. The console can be split into web page and backend service. The > > backend service can be deployed into the service cluster. It can be treated > > as a common micro-service, which means the security options of it can keep > > the same as other services. The web pages, if they are static page with > > html+js, can be deployed in the edge service. If users are concerned about > > the security issues, they can add authorization by themselves. > > I think this solution is flexible, but complex for many users. > > > > > > On conclusion, I guess if this feature is provided by service instances > > directly, it is less complex for us to implement it. While it may be not so > > practical in production environment. If this feature is provided by another > > console service, it's more complex, but there are more chances to apply it > > into a production environment. > > > > > > Yours sincerely > > > > > > Yao Haishi > > yhs0...@163.com > > > > > > On 3/5/2019 10:37??wjm wjm<zzz...@gmail.com> wrote?? > > this feature should be for both development and production environment, so > > must conside security problem. > > currently i'm not sure what's the best way to control it. > > > > yhs0092 <yhs0...@163.com> ??2019??3??5?????? ????10:28?????? > > > > That's a great idea! > > What is the positioning of this feature? If it's designed for development > > environment trouble-shooting, I guess it's okay the web pages are provided > > by the micro-service instances directly. But if this feature is expected to > > work in production environment, which may contains massive micro-service > > instances, maybe it's better that service instances provide RESTful > > interfaces, and users get access to these informations via the console > > service. > > > > > > Yours sincerely > > > > > > Yao Haishi > > yhs0...@163.com > > > > > > On 3/5/2019 09:52??wjm wjm<zzz...@gmail.com> wrote?? > > @zhang_lei > > > > ServiceComb can run with spring boot, but will not depend on spring boot. > > > > > > wjm wjm <zzz...@gmail.com> ??2019??3??5?????? ????9:49?????? > > > > href of gif: > > > > https://issues.apache.org/jira/secure/attachment/12961084/swaggerAndDocument.gif > > and more question: > > how to define the security of the new feature > > should open a new port for the feature? > > > > > > wjm wjm <zzz...@gmail.com> ??2019??3??5?????? ????9:20?????? > > > > currently it's difficult to collect internal status of a microservice > > instance when some problem happened. > > eg: > > routing depend on cached instances, discovery tree, strategy of > > governances, and so on > > when we resolving routing related problem, we can only guess the status > > of all related modules. > > > > > > so we should provide a way to inspect the internal status of a > > microservice instance at runtime, maybe include: > > discovery tree > > isolation > > eventbus > > view schemas as swagger or html/pdf...... > > ...... > > maybe like the gif: > > > > > > > > > > my question: > > provide these informations include related html/js/css by instance > > directly, or only by governance console > > if provide by both instance and governance console, that will cause > > duplicate development > > > > if provide by instance > > what's the name of the module? "inspector"? > > swagger to html depend on "asciidoctor", which depend on jruby, it's very > > heavy. > > in my demo, resource of swagger and asciidoctor all load from cdn, but for > > some customer's environment, maybe can not connect to internet. > > any other idea? > >
